Terraform Provider 認証パターン実践ガイド: 環境変数・プロファイル・OIDC

Terraform の認証は Provider ごとに実装され、優先順位や対応変数も異なります。試験では「どのパターンがどの場面に適合するか」「安全に自動化する設計を選べるか」が問われます。

ここでは AWS/Azure/GCP を軸に、環境変数・共有プロファイル・OIDC（フェデレーション）の3系統を比較し、CI/CD とローカルの両方で安定運用する指針をまとめます。

プロバイダ認証の原則と優先順位

Terraform のコアは認証を持ちません。各 Provider が認証の探索順序（優先順位）を実装します。多くの公式 Provider では、明示設定 > 環境変数 > 共有プロファイル/CLI 認証 > インスタンス/メタデータといった順で探索されますが、正確な順序や対応キーは Provider ごとに異なります。

試験対策の基本は「明示的な provider ブロック設定が最優先」「環境変数は CI/CD と相性が良い」「ローカル開発では共有プロファイル/CLI が楽」「本番の自動化は OIDC/フェデレーションで短期資格を使う」の4点を押さえることです。優先順位の細部は各 Provider の公式ドキュメントを確認してください。

• 明示設定が最優先（例: provider ブロックに client_id/role_arn 等）
• 環境変数は非対話・コンテナで有効（CI/CD 向き）
• 共有プロファイル/CLI はローカル開発で便利（例: ~/.aws/credentials, gcloud ADC, az login）
• メタデータ/IMDS は実行環境がクラウドの場合のフォールバック
• 優先順位は Provider ごとに異なるため設計前に確認する

最小構成（既存の認証連鎖に委ねる）

terraform {
  required_providers {
    aws = { source = "hashicorp/aws" }
  }
}

provider "aws" {
  # credentials/profile/env/IMDS いずれかで解決
  region = var.region
}

環境変数パターン（ローカルとCIの両対応）

環境変数は非対話環境に最適で、CI/CD との親和性が高い方法です。AWS ならアクセスキーや一時トークン、Azure なら ARM_* 変数、GCP なら ADC（GOOGLE_APPLICATION_CREDENTIALS=外部アカウントJSON含む）を使います。長期キーの直置きは避け、可能なら短期資格（セッション/トークン）を使います。

Terraform 側の provider ブロックは最小に保ち、環境変数で埋めるのが定石です。環境変数が不備だと初期化時に認証エラーとなるため、CI ではマスク・権限スコープ・期限を合わせて管理します。

• AWS: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION
• AzureRM: ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, ARM_SUBSCRIPTION_ID
• GCP: GOOGLE_APPLICATION_CREDENTIALS（JSONパス。外部アカウントJSONでWIFにも対応）
• 長期キーは避け、短期・ローテーションを前提にする

環境変数の例（macOS/Linux）と最小 provider

# AWS（短期セッション例）
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
export AWS_REGION=ap-northeast-1

# Azure
export ARM_CLIENT_ID=00000000-....
export ARM_TENANT_ID=11111111-....
export ARM_SUBSCRIPTION_ID=22222222-....
export ARM_CLIENT_SECRET=...   # 可能ならOIDCへ移行

# GCP（ADC）
export GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gcloud/application_default_credentials.json
# もしくは外部アカウントJSON（WIF）へのパス

# Terraform 側は最小
provider "aws" { region = "ap-northeast-1" }
provider "azurerm" { features {} }
provider "google" { project = var.project region = var.region }

共有プロファイル/CLI パターン（ローカル最適・学習しやすい）

ローカル開発では共有プロファイルや CLI ログインが実用的です。AWS は ~/.aws/credentials と ~/.aws/config の profile、Azure は az login（デバイスコード/ブラウザ）からのトークン、GCP は gcloud auth application-default login による ADC が定番です。

CI へはそのまま持ち込まず、CI では別途 OIDC/短期資格へ切り替えるのが安全です。試験でも「ローカル=プロファイル、CI=OIDC」の切り分けを選べるかが頻出です。

• AWS: provider "aws" { profile = "dev" } で共有クレデンシャル参照
• GCP: ADC は優先的に参照される（GOOGLE_APPLICATION_CREDENTIALS > gcloud ADC > メタデータ）
• Azure: az login 済みの場合、Managed Identity/CLI 認証がフォールバックになることがある

AWS プロファイルと GCP ADC の例

# ~/.aws/credentials
[dev]
aws_access_key_id=AKIA...
aws_secret_access_key=...

# ~/.aws/config
[profile dev]
region=ap-northeast-1

# Terraform 側
provider "aws" {
  profile = "dev"
  region  = "ap-northeast-1"
}

# GCP（ADC）作成コマンド（ローカル開発）
# gcloud auth application-default login
# → provider "google" は ADC を自動検出

OIDC/フェデレーション（CI/CD本命・長期秘密ゼロ）

CI/CD からの安全な認証は OIDC/フェデレーションが基本です。長期シークレットを持たず、ワークフロー実行時に OIDC トークンを発行し、クラウド側で信頼関係を設定して一時的な権限に昇格します。AWS は sts:AssumeRoleWithWebIdentity、Azure は Entra ID の Federated Identity Credentials、GCP は Workload Identity Federation（external_account JSON）を用います。

Terraform の provider ブロックは最小でよく、多くの場合は環境変数とクラウド側のロール/ID 設定で完結します。トラストポリシーの条件（audience、issuer、sub）不一致やトークン有効期限切れが典型的な失敗要因です。

• AWS: AWS_ROLE_ARN と AWS_WEB_IDENTITY_TOKEN_FILE（または SDK 自動検出）
• Azure: Entra ID に Federated Identity を作成し、クライアントID/テナントIDとOIDCトークンで認証
• GCP: external_account JSON を GOOGLE_APPLICATION_CREDENTIALS で指す（または ADC チェイン）
• OIDC は最小権限ロール＋条件付きトラストが前提

CI からの OIDC フロー（概念）

 [CI/CD Job]
      |
      | 1. 要求 (aud, sub, repo 情報)
      v
 [OIDC Provider] ---- 2. OIDC トークン発行 ---->
      |
      | 3. トークン提示 (Assume / Exchange)
      v
 [Cloud STS/Identity] -- 4. 一時資格発行 --> [Provider SDK]
      |
      v
 [Terraform Apply]

AWS（GitHub Actions OIDC）の最小例

# GitHub Actions の主要部分（概念例）。実運用では公式アクションを推奨。
# permissions: id-token: write が必要

# env はジョブ内でセット（トークンはファイルパスで提供される）
# AWS_ROLE_ARN=arn:aws:iam::123456789012:role/gha-oidc-role
# AWS_WEB_IDENTITY_TOKEN_FILE=/path/to/gha/oidc-token
# AWS_REGION=ap-northeast-1

provider "aws" {
  region = "ap-northeast-1"  # 認証は環境変数で完結
}

CI/CD 設計の実践的な選択基準

セキュリティ（長期秘密の無置換）、権限の最小化、短期資格の自動ローテーション、失敗時の再実行容易性の観点で OIDC/フェデレーションが第一候補です。例外は、対象クラウドや実行環境が OIDC に未対応な場合で、そのときのみ短期キーの環境変数を暫定利用します。

Terraform Cloud/Enterprise を使う場合も、変数は VCS/ワークスペース側で環境変数として安全に注入し、機密は Sensitive フラグを付けます。

• 原則: CI は OIDC、ローカルは プロファイル/CLI、緊急時のみ短期キー
• エラー解析は Provider の DEBUG ログ（TF_LOG=DEBUG）でトレース
• リージョン/プロジェクト/テナントIDの取り違えが定番の初歩ミス

Terraform Cloud での代表的な環境変数（例）

# ワークスペース変数として設定（Sensitive 指定）
# AWS OIDC の例（実際はVCS側/実行環境が注入）
AWS_ROLE_ARN=arn:aws:iam::123456789012:role/tfc-oidc-role
AWS_WEB_IDENTITY_TOKEN_FILE=/workspace/oidc/token
AWS_REGION=ap-northeast-1

試験対策の要点とトラブルシュート

頻出ポイントは、認証探索順序の理解、環境変数名の正確さ、ローカルとCIの設計切り替え、OIDC の信頼条件（issuer, audience, subject）の一致、そして短期資格の更新です。選択式では「長期シークレットを保存する」選択肢は基本的に誤りです。

実務の初動は、まず provider を最小構成で動かし、DEBUG ログでどのクレデンシャルが選ばれているかを確認することです。次に CI へ移行し、OIDC で同等の挙動になるようクラウド側ロールとトラストを整えます。

• TF_LOG=DEBUG で SDK の認証探索を確認
• AWS は sts:AssumeRoleWithWebIdentity のポリシー条件を点検
• Azure は Entra ID の Federated Identity Credentials を適合するスコープで作成
• GCP は external_account JSON の audience/subject_token_type を再確認
• ExpiredToken, AccessDenied, configuration not found は入口の手がかり

AWS 共有プロファイル + AssumeRole（ローカルから昇格）の例

provider "aws" {
  profile = "dev"
  region  = "ap-northeast-1"
  assume_role {
    role_arn     = "arn:aws:iam::123456789012:role/admin"
    session_name = "tf-local-dev"
  }
}

問題で確認

よくある質問