bitFlyer Advent Calendar 2022 第18天的介绍。

大家好。最近为了提高居家时间的生活质量，我迷上了DIY，在入口处增设了一些货架。我是bitFlyer SRE部门的遠地。

本文将介绍我们如何为Azure构建Terraform Cloud，并分享一些相关的经验。

太长不看

• 「開発と運用の職務分離」や「最小権限の原則」のために、Terraform Cloudの設定自体をコード化

• いくつかの落とし穴回避ポイント

ドメインapp.terraform.ioを社内プロキシの対象から外す
Azure DevOpsのApplicationの追加はProject Collection Administrator権限を持ったユーザで行う
Terraform CloudのユーザはActive Directory側で定義

Terraform Cloudにprojectの概念が欲しかった日々だった

背景

在一个下午，令和酱（一名四岁的孩子）正在玩气压滑梯。一位SRE工程师十分苦恼。由于服务数量增加，他希望有更多的人能够使用terraform。

在我们公司目前正在进行微服务迁移项目。是的，这意味着我们要在云上管理越来越多的基础设施。因此，SRE部门将基础设施转化为terraform代码，并将管理权交给了开发团队，以确保不成为瓶颈。

然而，随着terraform存储库的增加，CI/CD和tfstate的管理以及工作流程说明的负担也逐渐增加。因此，”让我们引入Terraform Cloud！让大家能够更轻松地使用！” 这个大浪潮必然会到来，PoC已经揭开了序幕。

重要文件

由于我们公司属于金融行业，因此需要严格的访问控制。

• 開発と運用の職務分離

• サービスの開発をする人と、デプロイ・保守する人を分ける。

• 最小権限の原則

最低限必要なアクセス権限だけを付与する。

另外，在以下所述的环境条件下进行配置。

• クラウドはAzureを使用

Active DirectoryでSSO連携

换句话说，我们希望在满足“开发和运维的职责分离”以及“最小权限原则”的要求的前提下，通过在Terraform Cloud中与Azure进行SSO集成，在Active Directory中构建Azure资源。

構成的考虑 de

为了实现“开发与运维职责分离”，我们将设立开发团队和运维团队。开发团队仅能访问验证环境，而运维团队可以访问验证环境和正式环境。

在Terraform Cloud的配置中，我认为您可以从以下两个选项中选择。

• 2つのorganizationを使って根本から分離

1つのorganization内でチームの機能を使って分離

是指像下面这个表格一样的情况对吗？

如果是由多个组织构成，就可以明确地分隔开来，这样让人感到安心。然而，如果是由单一组织构成，有以下多种好处。

• 開発チームは本番環境のterraform planの結果を同一organization内で確認できる

• Registry moduleが一箇所で済む

Organization毎に発生するライセンス料を節約できる

因此，我们公司选择了单一组织结构。为了有效地管理团队的划分，我们会将Terraform Cloud的配置代码化，并建立相应的CI/CD环境。

造成的案子

• Active DirectoryでSSO連携します。

• Active Directoryのgroupと、Terraform Cloud上のteamを対応させます。

Terraform Cloudのteamごとのアクセス制御をコード化し、Azure DevOpsにCI/CDパイプラインを構築します。

步驟

在Active Directory中进行单点登录(SSO)集成。

在構建SSO連接時，我們將參考Microsoft Azure AD – Single Sign-on。

将Active Directory的群组与Terraform Cloud上的团队进行对应。

将Active Directory进行配置

微软Azure AD – 单点登录的”团队和用户名属性”项中有说明，但需要先掌握Active Directory知识才能理解，难度较高。因此，下面将展示实际的建立步骤。

在Terraform Cloud上设置SSO团队ID。

请记下Active Directory中群组的Object ID。
Terraform Cloud › 组织设置 › 团队
在「SSO团队ID」中输入Object ID，然后点击「更新团队」按钮。
请重复此操作，以适用于所有团队。

通过上述的步骤，应该可以将Active Directory中的群组与Terraform Cloud上的团队进行对应。请使用SSO进行登录并进行确认。

将Terraform Cloud中每个团队的访问控制编码化。

那么，我们来让Azure DevOps的Pipelines能够进行Terraform Cloud的配置。

添加VCS提供者

根据 Terraform Cloud 的参考，我们将添加 VCS 提供商到 Azure DevOps Services。

生成 Terraform Cloud令牌。

使用 Terraform Cloud API Tokens 作为参考，在管理体制中生成与 Terraform Cloud 兼容的令牌，并将其存储在可以从 Terraform Cloud CI/CD 管道中作为环境变量 TFE_TOKEN 访问的位置。（我们公司将其存储在 Azure Key Vault 中。）

添加VCS提供商

借鉴Azure DevOps Services – VCS提供者 – Terraform Cloud的概念，在Azure中注册了一个用于存放terraform代码版本的版本控制系统。

設置Azure身份验证信息

将Azure资源操作的Service Principal的认证信息放入Terraform Cloud的Variable Sets中。

ARM_SUBSCRIPTION_ID
ARM_TENANT_ID
ARM_CLIENT_ID
ARM_CLIENT_SECRET  # sensitive attributeとして追加

在测试环境和生产环境中，分别进行定义。

编写代码以控制Terraform Cloud的团队、工作区和变量集的访问控制。

在编写代码时，参考TFE提供商的指南，进行访问控制。

通过Terraform Cloud，现在已经完成在Azure上构建资源的准备工作?

讲解

为什么要通过Active Directory而不是代码来进行团队分组？

在Terraform Cloud中存在一个名为“组织成员ID被重新分配问题”的问题。
例如，我们预先定义了用户的成员资格情况，并在tfe_organization_membership中进行了设置。然后，当用户首次使用SSO登录时，会导致新的ID（组织成员ID）被分配，并导致tfstate与之不一致。

换句话说，我们无法提前定义”用户所在的团队状态”，因此我们需要采取下列任一避免方案。

• SSOサインインを待ってからCI/CDを走らせる

あるいは、新しく振られたIDをterraform importする

为了避免操作的复杂程度增加，我们放弃了使用terraform定义用户所属团队，并决定在Active Directory的群组中进行定义。

创建Azure DevOps应用程序时，需要注意以下几点：
– 必须以Project Collection管理员的身份进行创建。

我们需要由拥有项目集合管理员权限的人员创建Azure DevOps应用程序。

虽然将具有如此强大权限的应用程序连接到Terraform Cloud的Azure DevOps集成存在风险，但另一方面，如果不对工作区创建进行编码，管理者级别的人员将需要处理所有工作区的创建，这非常繁琐。

因此，对于Terraform Cloud的代码审查等，需要采取措施来防止错误代码的混入。

曾经有过渴望拥有Terraform Cloud项目这个概念的日子。

这次我们以“开发团队”和“运营团队”分开的例子为例，但是如果按照这个例子，只需创建一个“验证环境”和“生产环境”的项目，然后定义团队和项目的关系，就可以简化 Terraform Cloud 的设置。

正在招聘工程师！

bitFlyer正在寻找对日常进行工作流程改进、服务稳定性和效率提升的SRE工程师以加入我们的团队。如果您对此感兴趣，请务必申请！