azure - 授予 Terraform 服务主要贡献者但从 Key Vault 中删除

Question

我们正在 Azure Government 中构建一个解决方案，并将使用 Terraform 来部署该解决方案。似乎首选方法是为 Terraform 创建一个服务主体，该服务主体的贡献者角色范围仅限于订阅。

我们希望解决的一个问题是，这使服务主体管理平面能够访问 Key Vault...因为它位于订阅中。对于贡献者角色，服务主体无法创建新的访问策略(将其自身或其他人分配给数据平面的权限)，但我们正在寻找一种方法来删除服务主体的任何管理平面权限。

我们尝试在创建服务主体之前在 Key Vault 上设置只读锁，但该锁不会阻止服务主体获取 Key Vault 上的贡献者权限。

除了创建一个新角色，让 Contributor 负责除 Key Vault 之外的所有事情之外，还有人有任何可能有助于实现这一目标的创意吗？

Answer 1

是的，所有安全问题的根本原因是服务主体的贡献者角色分配是在订阅级别/范围内的，这使得它能够造成相当大的损害，特别是如果多个应用程序部署到同一个订阅(例如删除任何资源)组)。

一种方法是:

1. 为特定于应用程序和区域的 Azure Key Vault 配置一个资源组(如果是地理分布式应用程序，则为后者)。
2. 在上一步创建的资源组上配置 Azure Key Vault。

In our case, the Security Office was responsible for the first 2 steps, where they had monitoring (e.g. email, text-messages, etc.) for any change in the Azure Key Vault (e.g. new keys/secrets/certificates added/deleted/changed, permission changes, etc.).

配置第二个资源组，它将用作应用程序组件(例如 Azure Function、Azure SQL Server/数据库、Azure 服务总线命名空间/队列等)的容器。<

创建服务主体并将贡献者角色分配给仅应用程序资源组，例如:范围=
/subscriptions/{订阅 ID}/resourceGroups/{资源组
姓名}

Find a sample PS script to provision a Service Principal with custom scope at https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.

为 Azure 中的服务主体授予适当的权限 keystore 。在我们的例子中，我们决定有单独的服务用于部署( key / secret /证书的读写权限)和运行时( key / secret /证书的只读权限)的主要帐户；

Find a sample PS script to set Service Principal permission on an Azure Key Vault at https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.

<小时/>

话虽如此，这种方法有很多不便，例如:

• 配置 Azure Key Vault(包括其资源组)和应用程序资源组的流程(例如通过 Runbook)将位于负责应用程序组件的主 Terraform 模板之外，这需要与不同团队/流程进行协调/工具/等等
• 涉及连接的实时站点通常需要多个团队之间的协调，以确保实现 RTO 和 MTTM(平均缓解时间)目标。
• 执行terraform destroy时，服务主体将能够删除应用程序特定资源组，但它将无法重新创建它当运行 terraform apply 时，由于缺乏订阅级别/范围的权限。错误如下:

provider.azurerm:无法列出提供程序注册状态，这可能是由于凭据无效或服务主体无权使用资源管理器 API，Azure 错误:resources.ProvidersClient#List :响应请求失败:StatusCode=403 -- 原始错误:autorest/azure:服务返回错误。 Status=403 Code="AuthorizationFailed"Message="对象 ID 为 '' 的客户端 '' 无权在范围 '/subscriptions/{Subscription Id}' 上执行操作 'Microsoft.Resources/subscriptions/providers/read'。 ”。

<小时/>

是的，我知道，这是一个很长的答案，但该主题通常需要大量的跨团队讨论/集思广益，以确保满足安全办公室建立的安全控制，开发人员的生产力不会受到影响它将影响发布时间表和 RTO/MTTM 目标的实现。我希望这能有所帮助!