Azure：使用Terraform的服务主要用户最佳实践

Question

当我们使用Terraform管理Azure上的基础架构时，我对如何使用服务原则用户感到有点困惑。

例如，是否建议让整个团队共享一个SP？或者我们是否需要为每个用户设置SP？

如果每个用户使用SP，会导致某些资源出现问题，例如本应配置了一个SP用户的密钥保险库，因此已为该用户定义了访问策略，而团队中的另一个人则使用了不同的SP无法从他们的笔记本电脑中修改该保险库。

不确定我的问题是否足够清楚，但未能找到有关这些方案的具体细节。

非常赞赏

Answer 1

当您执行操作的服务（非人工）时，应使用服务主体。例如，在这种情况下，Terraform将使用服务主体将您的基础架构配置为CI / CD管道的一部分。

服务主体（在任何环境中）通常配置为最小权限。这样做的原因是服务主体旨在用于单个且非常特定的目的，例如调用Terraform来配置您的环境。因此，您的服务主体可能有权读取Azure Key Vault中用于在特定资源组（或一组资源组）中配置资源的一组特定机密。那就是它。

将此与用户帐户进行比较，例如您用于执行工作的帐户。您可以访问多个Azure订阅，可以在任何地方配置资源，删除资源，配置对资源的访问等。

使用服务主体的主要原因归结为安全性。使用上面的示例，如果服务主体的凭证（客户端ID和机密）被泄露，那么用这些凭证唯一可以做的就是从密钥保险库读取密钥并在特定资源组中提供资源。

文档here演示了为整个订阅提供服务主体贡献者的权限。这比我上面给出的例子限制性更小。但是，我怀疑它是假设另一种最佳实践，即您的开发/测试环境应该使用与您的生产和其他环境不同的Azure订阅。因此，虽然服务主体对专用于dev / test的订阅具有完全的Contributor权限，但它仍然无法访问组织所拥有的其他订阅，也无法用于配置访问到资源中。订阅。

Answer 2

这是我推荐的模型。我们主要在我的公司（大约 40 人左右的技术团队，包括基础设施和开发人员）实施了它，并且运行良好。

1. 生产订阅与开发和测试分开（正如@RickRainey 建议的那样）。
2. prod 已锁定，因此只有“部署者”服务主体 (SP) 可以进行更改（以及一些基础设施管理员，以防万一）。 Deployer SP 通过我们的部署管道（在我们的示例中为 TeamCity）运行 terraform。
3. 开发人员拥有对开发环境的贡献者访问权限，在那里他们可以自由地试验和测试基础架构更改。他们使用自己的个人帐户而不是 SP（再次向 @RickRainey 大喊）这样做。
4. 任何人都可以将 terraform 更改推广到 prod，但必须通过 github 拉取请求 (PR)，由基础架构团队成员批准，并由部署者 SP 通过部署管道应用。

这实现了几个目标： a) 最低权限（产品被锁定）， b) 变更批准， c) 开发环境中的开发人员自由， d) prod 环境的透明度和可访问性（因为任何人都可以查看 terraform 并创建 PR）。

要做到这一切都存在一些明显的挑战（例如，如何在部署管道中保护 SP 的凭据），但没有什么是聪明的团队无法弄清楚的。