Terraform Dynamic Credentials 実践ガイド（OIDC でのクラウド認証／Pro対策）

動的認証情報（Dynamic Credentials）は、Terraform 実行時にだけ有効な短期クレデンシャルをクラウドから払い出す仕組みです。Terraform Cloud/Enterprise（TFC/TFE）の OIDC フェデレーションを用いると、ワークスペース毎・実行単位での安全な権限付与が可能になります。

本稿では、TFC/TFE を OIDC 発行者として AWS/Azure/GCP にフェデレーションする実務の要点と、試験（Pro 想定）で押さえるべき設計論点を整理します。静的な長期キーを無くすこと、最小権限・短寿命・スコープ分離を徹底することが中核です。

なぜ Dynamic Credentials（OIDC）か：要点と比較

長期キー（例: AWS Access Key、Service Principal 秘密、JSON キーファイル）は漏えい時の影響が大きく、ローテーション運用も重い。一方、OIDC を使った動的認証情報は、Terraform の実行要求に応じてクラウド側の STS/トークン発行エンドポイントで短期資格を払い出し、実行終了とともに失効します。TFC/TFE が OIDC 発行者となり、クラウド側に信頼関係（トラスト）を設定するのが基本構成です。

設計の原則は次の3点に集約されます。1) ワークスペース/実行単位のスコープ化、2) クラウド側ロール/ID の最小権限、3) セッション寿命の短縮とローテーションの自動化。これらは公式ドキュメントで推奨される安定的なベストプラクティスに一致します。

• TFC/TFE は OIDC 発行者。クラウド側に信頼（Issuer/Audience/Subject など）を定義
• Terraform 実行時のみ STS/Token Exchange で短期資格を取得
• プロバイダ設定に静的キーを埋め込まない（環境変数/ランタイム連携を利用）
• 最小権限ロール、ワークスペース単位の分離、タグ/クレームでのスコープ制御

TFC/TFE とクラウドの OIDC フロー全体像

Terraform 実行環境（TFC/TFE のエージェント/ランナー）が OIDC トークンを取得し、各クラウドの STS/トークンエンドポイントで交換、短期資格を得てプロバイダが API を実行します。信頼設定はクラウド側（ロール・アプリ・WIF プール）に保持し、TFC/TFE は実行単位のクレームを発行します。

ネットワーク要件としては、ランナーからクラウドの STS/ID エンドポイントへ到達可能であることが必要です。トラスト条件（Issuer, Audience, 必要に応じて Subject/クレーム）は、TFC/TFE 側の設定画面で提示される値とクラウド側の信頼設定を一致させます。

• ランナーが TFC/TFE の OIDC 発行者からトークンを取得
• クラウド STS/ID にトークンを提示して短期資格へ交換
• Terraform プロバイダは環境連携/デフォルト認証連鎖で短期資格を使用
• 実行終了で資格は失効（長期キーを保持しない）

TFC/TFE とクラウドの OIDC フロー

プロバイダは静的キー不要（環境連携に委ねる）

# 例：main.tf（抜粋）。認証情報の明示は不要（TFC/TFE の動的資格を利用）
terraform {
  required_providers {
    aws     = { source = "hashicorp/aws", version = ">= 5.0" }
    azurerm = { source = "hashicorp/azurerm", version = ">= 3.0" }
    google  = { source = "hashicorp/google", version = ">= 5.0" }
  }
}

provider "aws" {
  region = var.aws_region
}

provider "azurerm" {
  features {}
}

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
}

# 動作確認：実行時の呼び出し主体（例：AWS）
data "aws_caller_identity" "current" {}
output "aws_caller_arn" { value = data.aws_caller_identity.current.arn }

AWS 連携：IAM OIDC + STS（AssumeRoleWithWebIdentity）

AWS では、IAM に OIDC プロバイダを登録し、信頼ポリシーを持つロールを作成して STS の AssumeRoleWithWebIdentity を許可します。ロールには最小権限のポリシーを付与し、セッション継続時間は要件に応じてロール側で制御します。

TFC/TFE のワークスペースで AWS 動的認証を有効化すると、実行環境に必要な環境変数（Web Identity トークンファイルやロール指定など）が設定され、AWS プロバイダはそれを用いて短期資格を自動取得します。静的な access_key/secret_key の設定は不要です。

• IAM: OIDC プロバイダ登録（Issuer は TFC/TFE の URL）
• IAM: 信頼ポリシー付きロール作成（audience/subject 等の条件は TFC/TFE 指示に一致）
• 最小権限ポリシーをロールに付与
• Terraform 側はプロバイダに資格を直書きしない（環境連携で利用）

AWS プロバイダ例（短期資格での実行を前提）

provider "aws" {
  region = var.aws_region
}

# 実行主体の確認
data "aws_caller_identity" "me" {}
output "aws_principal" {
  value = data.aws_caller_identity.me.arn
}

# ベストプラクティス：
# - ここに access_key/secret_key を書かない
# - ロールの信頼条件はワークスペース/組織単位でスコープ化する

Azure 連携：Microsoft Entra ID の Federated Credential

Azure では、アプリ登録（サービスプリンシパル）に Federated Credential を作成し、Issuer/Audience/Subject を TFC/TFE の OIDC 設定に合わせます。ロール割り当てはスコープ最小化（リソースグループ単位など）を基本とし、必要最小限の組み合わせに留めます。

TFC/TFE のワークスペースで Azure 動的認証を有効化すると、Azure SDK/プロバイダが参照する環境変数（クライアント ID、テナント ID、フェデレーテッドトークンファイル等）が実行時に提供され、明示的なクライアントシークレットは不要になります。

• アプリ登録（SP）作成 → Federated Credential を追加
• Issuer/Audience/Subject を TFC/TFE 指示通りに設定
• ロール割り当ては最小権限・最小スコープ
• Terraform 側ではシークレットを持たず、環境連携に委ねる

AzureRM プロバイダ例（動的資格前提）

provider "azurerm" {
  features {}
}

# 動作確認（例）：現在のサブスクリプション
data "azurerm_subscription" "current" {}
output "azure_subscription_id" {
  value = data.azurerm_subscription.current.subscription_id
}

# ベストプラクティス：SP のクライアントシークレットは作成しない（Federated Credential を使用）

GCP 連携：Workload Identity Federation（WIF）

GCP では、Workload Identity Pool/Provider を作成し、TFC/TFE の OIDC Issuer を信頼させます。必要に応じてサービスアカウントの偽装（impersonation）を組み合わせ、実行に必要なロールのみを付与します。

TFC/TFE のワークスペースで GCP 動的認証を有効化すると、Google Provider/ADC が参照する実行時情報が付与され、外部アカウント経由で短期トークンが交換されます。サービスアカウントの長期キー（JSON キー）を発行・保存する必要はありません。

• WIF プール/プロバイダ作成（Issuer とクレーム条件を TFC/TFE に合わせる）
• サービスアカウントに最小権限を付与、必要に応じて偽装を使用
• 長期キー（JSON キー）は発行しない
• Terraform 実行は ADC/環境連携で短期資格を利用

Google プロバイダ例（動的資格前提）

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
}

# 呼び出し主体の確認（プロジェクト情報）
data "google_project" "current" {}
output "gcp_project_number" {
  value = data.google_project.current.number
}

# ベストプラクティス：サービスアカウントの JSON キーを使わない（WIF を使用）

試験対策と運用の落とし穴

試験（Pro 想定）では、静的キー排除、OIDC フェデレーションの信頼境界、最小権限、ワークスペース単位のスコープ化、セッション寿命、監査可能性が頻出です。Terraform 側に資格情報を一切書かない構成が模範解答であることが多いです。

運用では、ワークスペース/環境（prod/stg）の分離、ロール/ID の命名規約、クレーム条件の過不足（広すぎる Subject や Audience の共有）、セッション時間の過大設定、失効後のリトライ設計、監査ログの一元化が落とし穴になりやすいです。

• ワークスペース毎に信頼条件を分離（運用/検証の誤用を防止）
• ロール／アプリ／SA は最小権限＋必要最小スコープで割当
• セッションは短め（原則デフォルト）に。延長は正当化が必要
• Terraform 構成・状態に長期資格を残さない（変数・出力にも載せない）
• 失敗時の観察点：OIDC Issuer 不一致、Audience/Subject 条件不一致、時刻同期、ネットワーク到達性

実行時に短期資格で動いているかを確認する小技（例：AWS）

# apply 後にロール ARN を確認し、想定の OIDC 用ロールになっているかを検証
# outputs.tf
output "caller_arn" {
  value = data.aws_caller_identity.me.arn
  description = "実行時の呼び出し主体（短期ロールであること）"
}

# 想定外の長期ユーザ/アクセスキー主体が出たら、動的資格が効いていないサイン

問題で確認

よくある質問