提供Terraform服务主要贡献者，但从Key Vault中删除

Question

我们正在Azure政府中构建解决方案，我们将使用Terraform部署解决方案。似乎首选的方法是为Terraform创建一个Service Principal，其中Service Principal的Contributor角色定为订阅。

我们希望解决的一个问题是，这使服务主管理平面能够访问密钥保管库...因为它在订阅中。使用Contributor角色时，服务主体无法创建新的访问策略（为数据平面分配自身或其他权限），但我们正在寻找一种可以删除服务主体以获得任何管理平面权限的方法。

我们尝试在创建服务主体之前在密钥保管库上放置一个ReadOnly锁定，但锁定并不会阻止服务主体获取密钥保管库上的贡献者权限。

除了创建一个新的角色，除了Key Vault之外，还有一个包含所有内容的贡献者，有没有人有任何可能有助于实现这一目标的创意？

Answer 1

是的，所有安全问题的根本原因是服务主体的贡献者角色分配处于订阅级别/范围，这使得它可以在多个应用程序部署到同一订阅时特别损坏（例如，删除任何资源组。）

一种方法是：

1. 为特定于应用程序和区域的Azure Key Vault提供一个资源组（后者适用于地理分布式应用程序）。
2. 在上一步创建的资源组上配置Azure Key Vault。

  

在我们的案例中，安全办公室负责前两个步骤，他们对Azure Key Vault中的任何更改进行监控（例如电子邮件，文本消息等）（例如添加了新密钥/机密/证书） /删除/更改，权限更改等。）。

1. 提供第二个资源组，它将作为应用程序组件的容器（例如Azure功能，Azure SQL Server /数据库，Azure服务总线命名空间/队列等）。
2. 创建服务主体，将贡献者角色分配给 仅限应用程序资源组，例如： scope = /subscriptions/{Subscription Id}/resourceGroups/{Resource Group Name}

  

查找示例PS脚本，以便在https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1配置具有自定义范围的服务主体。

1. 为Azure中的服务主体提供适当的权限 钥匙库。在我们的案例中，我们决定单独提供服务 主要负责部署（密钥/机密/证书的读写权限）和运行时（密钥/机密/证书的只读权限）;

  

查找示例PS脚本，以便在https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1的Azure Key Vault上设置Service Principal权限。

话虽如此，这种方法有很多不便之处，例如：

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

provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".

是的，我知道，这是一个很长的答案，但主题通常需要大量的跨团队讨论/头脑风暴来确保安全办公室建立的安全控制得到满足，开发人员的工作效率不会受到影响。它将影响发布时间表并满足RTO / MTTM目标。我希望这有点帮助！