Azure：使用 Terraform 的服务主体用户最佳实践
Azure: Service principal user best practice with Terraform
当我们使用 Terraform 在 Azure 上管理我们的基础设施时，我对我们应该如何使用服务原则用户感到有点困惑。
比如，是否推荐一个SP供全队共享？还是我们需要为每个用户设置一个 SP？
如果它的 SP 每个用户，这会导致某些资源出现问题，例如本应由一个 SP 用户提供的密钥保管库，因此已经为该用户定义了访问策略，而团队中的另一个人则具有不同的 SP 将无权从他们的笔记本电脑修改该保管库。
不确定我的问题是否足够清楚，但未能找到有关这些场景的具体细节。
非常感谢
当您有 服务（非人类）执行操作时，应使用服务主体。例如，在这种情况下，Terraform 将使用服务主体将您的基础设施配置为 CI/CD 管道的一部分。
服务主体（在任何环境中）通常配置为最低权限。这样做的原因是服务主体旨在用于单一且非常具体的目的，例如调用 Terraform 来配置您的环境。因此，您的服务主体可能有权从 Azure Key Vault 读取一组特定的机密，这些机密用于在特定资源组（或一组资源组）中预配资源。就是这样。
将此与用户帐户进行比较，例如您用来完成工作的帐户。你可以访问多个 Azure 订阅，可以在任何你想要的地方配置资源、删除资源、配置对资源的访问等等。
使用服务主体的主要原因归结为安全性。使用上面的示例，如果服务主体的凭据（客户端 ID 和机密）被泄露，那么使用这些凭据唯一可以做的就是从密钥保管库中读取机密并在特定资源组中配置资源。
文档 here 演示了向服务主体贡献者授予对整个订阅的权限。这比我上面给出的例子限制更少。但是，我怀疑它假设了另一种最佳实践，即您的 dev/test 环境应该使用与您的生产环境和其他环境不同的 Azure 订阅。因此，虽然服务主体对专用于 dev/test 的订阅具有完全贡献者权限，但它仍然无法访问组织拥有的其他订阅，也不能用于配置 access 到订阅中的资源。
这是我推荐的模型。我们主要在我的公司（大约 40 人的技术团队，包括基础架构和开发人员）实施了它，并且运行良好。
- 产品订阅与开发和测试分开（正如@RickRainey 所建议的）。
- prod 已锁定，因此只有“部署者”服务主体 (SP) 可以进行更改（在紧急情况下还有一些基础设施管理员）。 Deployer SP 通过我们的部署管道（在我们的例子中是 TeamCity）运行 terraform。
- 开发人员拥有对开发环境的贡献者访问权限，他们可以在其中自由试验和测试基础架构更改。他们使用自己的个人帐户而不是 SP（再次向@RickRainey 大声喊叫）。
- 任何人都可以将 Terraform 更改推广到产品，但必须通过 github 拉取请求 (PR)，由基础架构团队成员批准，并由部署者 SP 通过部署管道应用。
这实现了几个目标：
a) 最小权限（prod 被锁定），
b) 变更批准，
c）开发环境中的开发人员自由，
d) 生产环境的透明度和可访问性（因为任何人都可以查看地形并创建 PR）。
将这一切做到无懈可击有一些明显的挑战（例如，如何在部署管道中保护 SP 的凭据），但没有什么是聪明的团队无法解决的。
当我们使用 Terraform 在 Azure 上管理我们的基础设施时，我对我们应该如何使用服务原则用户感到有点困惑。
比如，是否推荐一个SP供全队共享？还是我们需要为每个用户设置一个 SP？
如果它的 SP 每个用户，这会导致某些资源出现问题，例如本应由一个 SP 用户提供的密钥保管库，因此已经为该用户定义了访问策略，而团队中的另一个人则具有不同的 SP 将无权从他们的笔记本电脑修改该保管库。
不确定我的问题是否足够清楚，但未能找到有关这些场景的具体细节。
非常感谢
当您有 服务（非人类）执行操作时，应使用服务主体。例如，在这种情况下，Terraform 将使用服务主体将您的基础设施配置为 CI/CD 管道的一部分。
服务主体（在任何环境中）通常配置为最低权限。这样做的原因是服务主体旨在用于单一且非常具体的目的，例如调用 Terraform 来配置您的环境。因此，您的服务主体可能有权从 Azure Key Vault 读取一组特定的机密，这些机密用于在特定资源组（或一组资源组）中预配资源。就是这样。
将此与用户帐户进行比较，例如您用来完成工作的帐户。你可以访问多个 Azure 订阅，可以在任何你想要的地方配置资源、删除资源、配置对资源的访问等等。
使用服务主体的主要原因归结为安全性。使用上面的示例，如果服务主体的凭据（客户端 ID 和机密）被泄露，那么使用这些凭据唯一可以做的就是从密钥保管库中读取机密并在特定资源组中配置资源。
文档 here 演示了向服务主体贡献者授予对整个订阅的权限。这比我上面给出的例子限制更少。但是，我怀疑它假设了另一种最佳实践，即您的 dev/test 环境应该使用与您的生产环境和其他环境不同的 Azure 订阅。因此，虽然服务主体对专用于 dev/test 的订阅具有完全贡献者权限，但它仍然无法访问组织拥有的其他订阅，也不能用于配置 access 到订阅中的资源。
这是我推荐的模型。我们主要在我的公司（大约 40 人的技术团队，包括基础架构和开发人员）实施了它，并且运行良好。
- 产品订阅与开发和测试分开（正如@RickRainey 所建议的）。
- prod 已锁定，因此只有“部署者”服务主体 (SP) 可以进行更改（在紧急情况下还有一些基础设施管理员）。 Deployer SP 通过我们的部署管道（在我们的例子中是 TeamCity）运行 terraform。
- 开发人员拥有对开发环境的贡献者访问权限，他们可以在其中自由试验和测试基础架构更改。他们使用自己的个人帐户而不是 SP（再次向@RickRainey 大声喊叫）。
- 任何人都可以将 Terraform 更改推广到产品，但必须通过 github 拉取请求 (PR)，由基础架构团队成员批准，并由部署者 SP 通过部署管道应用。
这实现了几个目标： a) 最小权限（prod 被锁定）， b) 变更批准， c）开发环境中的开发人员自由， d) 生产环境的透明度和可访问性（因为任何人都可以查看地形并创建 PR）。
将这一切做到无懈可击有一些明显的挑战（例如，如何在部署管道中保护 SP 的凭据），但没有什么是聪明的团队无法解决的。