しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Terraform Cloud に追加された Dynamic Provider Credentials を Azure Provider で試した

今朝に発表された Terraform Cloud のアップデートで OpenID Connect を利用した認証情報の取得に対応したようです。Dynamic Provider Credentials という名前で紹介されています。

GitHub Actions ではほぼ OIDC のみを使うようになりましたが、一番強い権限が必要な Terraform Cloud で使えなかったのが悩みの一つでした。GitHub Actions と Azure AD を組み合わせて利用する方法は以前に書いているので、以下の記事を参照してください。

Terraform Cloud を Azure Provider で利用する場合には期限付きの Client Secret を作成する必要があったので、Client Secret 自体の管理が必要になるというデメリットがかなり大きかったです。まだベータ扱いですが、ついにそんな悩みから解放されます。

早速 Terraform Cloud で Azure リソースを管理しているプロジェクトで有効化してみました。Azure 向けドキュメントは以下に用意されているので、これを読めば簡単に設定できます。

Dynamic Credentials が利用可能な AzureRM Provider と AzureAD Provider のバージョンが決まっているので、古いバージョンの場合は事前にアップデートしておく必要があります。

Azure AD で Federated Credential を追加する

既に Terraform Cloud を利用しているケースでは Service Principal が作成済みのはずなので、追加で Federated Credential を追加して Dynamic Credentials 向けの情報を登録します。

この辺りはドキュメントに書いている通りの値を入力すればよいのですが、Subject identifier が若干複雑なフォーマットになっています。特に Project と Workspace の関係で混乱しやすいと感じたので、注意深く入力した方が良いでしょう。

plan と apply で別々の Subject identifier が用意されているので、それぞれに Service Principal を作成して個別に権限を割り当てることも出来ますが、今回は同じ権限を与えることにしました。

Issuer と Subject identifier は Terraform Cloud が発行するトークンの isssub に一致している必要があります。以下のドキュメントにはトークンの詳細が載っているので、Federated Credential に設定する値のイメージが付きやすいと思います。

結果として Service Principal に追加した Federated Credentials は以下のようになりました。GitHub Actions 用に 1 つと、Terraform Cloud 用に 2 つを追加しています。

Client Secrets が空っぽになっていることが重要です。これで Client Secret の期限を管理する必要なく、更に安全に Azure リソースの管理が行えるようになります。

Terraform Cloud に環境変数を追加

Service Principal に Federated Credential の設定を追加すれば、後は Terraform Cloud 側の環境変数の設定だけで完了します。ドキュメントに記載のある通り Dynamic Credentials を利用するには TFC_AZURE_PROVIDER_AUTHTFC_AZURE_RUN_CLIENT_ID の設定が必須です。

その 2 つとは別に ARM_SUBSCRIPTION_IDARM_TENANT_ID は Client Secret の時と同様に必要になるので、削除せずに残しておけば問題ありません。

設定後に適当に新しく Plan の実行か GitHub 上で Terraform 定義の変更を行えば、Dynamic Credentials を使って Azure リソースへのアクセスが行われます。もし実行時にエラーが出た場合には Federated Credential 周りの設定を再確認すると良いです。

これで Azure リソースの管理からアプリケーションのデプロイまでを全て Client Secret を使うことなく、OIDC を使った期間の短いトークンで行えるようになりました。セキュリティ的にも有利ですし、何よりも期限の管理が必要ないというのは最高ですね。