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

Question

我有些困惑，我们在使用Terraform管理Azure基础架构时应该如何使用Service Principle用户。

例如，建议整个团队共享一个SP吗？还是每个用户都需要设置一个SP？

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

不确定我的问题是否足够清晰，但我无法找到关于这些情况的具体细节。

非常感谢。

- Hafiz

Answer 1

当您有一个执行操作的服务（非人类）时，应该使用服务主体。例如，在此场景中，Terraform将使用服务主体作为CI/CD管道的一部分来配置基础设施。

在任何环境下，服务主体通常都是使用最小权限进行配置的。这是因为服务主体旨在用于单个和非常特定的目的，例如调用Terraform来配置您的环境。因此，您的服务主体可能具有从Azure Key Vault读取特定一组机密信息的权限，这些机密信息用于在特定资源组（或一组资源组）中配置资源。仅此而已。

与您用于工作的用户帐户相比，这是不同的。您可能可以访问多个Azure订阅，可以在任何地方配置资源、删除资源、配置对资源的访问权限等。

使用服务主体的主要原因是出于安全考虑。以上面的示例为例，如果服务主体的凭据（客户端ID和密码）被泄露，那么可以使用这些凭据做的唯一事情就是从密钥保管库中读取一个密钥并在特定的资源组中配置资源。

文档here演示了如何为服务主体授予整个订阅的贡献者权限。这比我上面给出的示例不太严格。然而，我怀疑它假设另一个最佳实践，即您的开发/测试环境应该使用与生产和其他环境不同的Azure订阅。因此，虽然服务主体对专用于开发/测试的订阅具有完全的贡献者权限，但它仍然无法访问组织拥有的其他订阅，也不能用于配置对订阅中资源的访问。

- Rick Rainey

---

我仍然不清楚的一件事是，在同一个团队中是否建议使用单个主要用户，还是这违反了规范，因为我们都是从自己的笔记本电脑而不是从中央位置运行terraform。 - Hafiz

如果您都是在本地计算机上运行，则只需使用各自的用户凭据进行身份验证。 您的笔记本电脑不是“共享环境”。 您的同事的笔记本电脑也不是“共享环境”。 因此，服务主体在这里不适用。 同样，如果您有一个 CI/CD 流水线，其中 Terraform 是由自动化服务（非人类）调用的，那么您需要配置服务以使用服务主体。 - Rick Rainey

还有一件事...假设您为您的组创建了一个服务主体。现在，您必须告诉每个人要使用的客户端ID和密钥。因此，每个人都必须记住这些额外的凭据-这很糟糕。另外，没有任何东西阻止您或团队中的其他人忽略它并使用自己的用户凭据来验证和调用Terraform。回到我的第一个声明-当您有一个执行操作的服务时，应该使用服务主体。 - Rick Rainey

目前令人烦恼的事情是，在某些 Terraform 脚本中，我们必须传递 SP 凭据才能启动资源。如果我们使用一个 SP（比如我的）来配置资源，而另一个团队成员想要使用自己的 SP 更新该资源，则会导致问题出现，Azure 权限错误开始出现。因此，我们考虑使用一个单一的 SP。举个例子，创建 Vault 需要传递 SP 凭据给资源。 - Hafiz

KeyVault是您遇到的唯一资源吗？KeyVault是一种“特殊”的资源，应该采用不同的管理生命周期，以解决诸如虚拟机、数据库等解决方案中的其他资源。例如，您应该在不同的资源组中创建一个密钥保管库，并具有有限的访问权限（例如，可能只有您和另一个人）。然后，您的团队其余成员使用密钥保管库来检索他们需要的密码/密钥，使用您提供的URI。 - Rick Rainey

Answer 2

这是我推荐的模型。我们在公司（技术团队大约有40人，包括基础设施和开发人员）大多数情况下都已经实现了它，并且效果很好。

1. 生产订阅与开发和测试进行分离（如@RickRainey所建议的）。
2. 生产环境被锁定，只有“部署者”服务主体（Service Principal (SP)）可以进行更改（并且在紧急情况下还有几个基础设施管理员）。Deployer SP通过我们的部署管道（我们使用TeamCity）运行terraform。
3. 开发人员可以访问开发环境的Contributor权限，他们可以自由地尝试和测试基础架构变更。这是使用他们自己的个人帐户而不是SP完成的（再次向@RickRainey表示感谢）。
4. 任何人都可以促使terraform的更改到生产环境，但必须是通过github Pull Request（PR），由基础设施团队成员批准，并由Deployer SP通过部署管道应用。

这样做可以实现以下几个目标： a）最小特权（生产环境被锁定）， b）更改批准， c）开发人员在开发环境中的自由， d）生产环境的透明度和可访问性（因为任何人都可以查看terraform并创建PR）。

这样做当然会面临一些挑战（例如如何在部署管道中保护SP的凭据），但是，一个聪明的团队无法解决吗。

- jschmitter