Terraform Cloud の Teams: RBAC設計と権限管理を実務・試験の両面から押さえる

Terraform Cloud の RBAC は、Teams を軸に「組織」「プロジェクト」「ワークスペース」の3階層で成立します。どの層にどの権限を与えるか、そして権限がどのように合成（最終的に有効化）されるかを理解することが、運用の安定性と試験合格の双方に直結します。

本稿では、実務で踏む落とし穴（プロジェクト配下の新規ワークスペースへの継承や、Owners の強大権限、Plan権限の扱いなど）を具体的に解説しつつ、Terraform Cloud Proレベルの出題に対応できる要点を体系化します。

Teams と RBAC の全体像

Teams はユーザの集合であり、Terraform Cloud のRBAC適用単位です。Teamsに対して、組織レベル権限（例: ポリシー管理、VCSプロバイダ管理）と、プロジェクト/ワークスペースへのアクセス（例: Admin/Write/Plan/Read）を付与します。

最終的な有効権限は、同一チームに対して設定された複数のアクセス（プロジェクト経由、ワークスペース個別付与）が存在する場合、より強い権限が優先されます（最大権限が有効）。一方、組織レベル権限はワークスペースの実行権限を直接は付与しません（例: manage_workspaces は作成/削除を許可しますが、そのチームに自動でWrite権限は付与されない）。

• Owners チームは組織全体の管理権限を持つ特別チーム。最小人数で運用する。
• プロジェクト単位のアクセスは、配下の既存・将来のワークスペースに継承される。
• ワークスペース個別アクセスは、当該ワークスペースにのみ適用されるピンポイント設定。
• 有効権限は「プロジェクトアクセス」と「ワークスペース個別アクセス」のうち、強い方が採用される。
• Plan 権限（環境によっては表示/利用が限られる場合あり）は、適用不可で計画（特にスペキュレイティブプラン）に限定される。

tfe プロバイダ設定のスケルトン（後続セクションの例で詳細付与）

terraform {
  required_providers {
    tfe = {
      source  = "hashicorp/tfe"
      version = ">= 0.50"
    }
  }
}

provider "tfe" {
  hostname = "app.terraform.io"
  token    = var.tfc_token
}

variable "org" { type = string }

権限スコープと継承・優先度

Terraform Cloud のアクセスは「付与先スコープ」と「権限の強さ」の2軸で理解します。まず、プロジェクトアクセスは配下の全ワークスペースに波及し、将来作られるワークスペースにも自動適用されます。次に、個別のワークスペースアクセスは、そのワークスペースだけに対して明示的に権限を設定します。

優先度はシンプルで、同じチームに対して複数経路で権限が与えられる場合、より強い権限が最終的に有効化されます。たとえば、プロジェクトで Read、個別ワークスペースで Write を与えると、有効権限は Write です。なお、組織レベル権限（例: manage_workspaces）は、ワークスペースの実行権限（Applyなど）を直接は与えません。

• デフォルトは非許可（明示付与がなければアクセス不可）。
• プロジェクトアクセスは新規ワークスペースにも継承されるため、大枠の既定権限として有効。
• 例外的に強い/弱い権限を個別ワークスペースで上書き可能（最大権限が有効）。
• Owners は別格。運用では Owners の日常利用を避け、最小権限のカスタムチームで実行する。

プロジェクト配下の作成時に自動で継承されるアクセスの確認（擬似フロー）

# プロジェクトTeamAccess: Team X -> Project A (Read)
# 既存WS: A1, A2 にRead適用
# 新規WS: A3をProject Aに作成 -> 自動でRead適用
# 例外: A2のみ Team X に対し Write を個別付与 -> A2の有効権限はWrite（最大権限が有効）

権限セットの比較（Workspace/Project 権限）

Terraform Cloud では、Workspace/Project に対する代表的な権限セットとして Admin / Write / Read（および一部環境では Plan）が用意されています。以下は実務・試験で問われやすい操作と権限対応の要点です。

Plan は適用不可で、計画実行（特にスペキュレイティブプランの実行・閲覧）に限定されます。Write は実行キュー投入と適用を許可し、Admin はワークスペース設定の変更や削除など運用上の危険操作も可能です。Read は状態やログの参照のみに限定されます。

• Admin は設定変更/削除/ロック解除などの管理操作を含むため、限定的に付与する。
• Write はCI/CD実行用に一般的。Applyの扱いは組織ポリシー（Sentinel等）で統制する。
• Plan は適用禁止の保証が必要な監査的なユースケースで有効（環境により利用可否あり）。
• Read は出力値やログの参照、ドリフト監視等の最小権限に適する。

最小権限の観点での付与例（擬似ポリシー）

# 本テーブルに基づく運用方針例
# - CI/CD用チーム: Project = Write, 本番WSのみ個別で Plan（適用させない）
# - 管理者チーム: 限定プロジェクトに Admin
# - 監査チーム: Read のみ

チームトークンと自動化（CI/CD統合の勘所）

チームトークンはAPI経由の自動化で利用する共有トークンです。スコープは当該チームに付与された組織/プロジェクト/ワークスペース権限に厳密に制限され、ユーザトークンより運用リスクを抑えられます。

実務では、プロジェクトに Write を付与したチームのトークンをCIに登録し、個別に Admin が必要な一部ワークスペースのみ別チームか個別付与で扱うのが安全です。トークンは定期ローテーション・利用権限の棚卸しと監査ログの確認を組み合わせて運用します。

• チームトークンは最小権限で払い出し、環境別（dev/stg/prod）に分離する。
• 人の個人トークンをCIに置かない。入退社・権限変更の影響を切り離す。
• 組織レベル権限は自動化に必要な分（例: manage_run_tasks, manage_variable_sets 等）だけ付与。

tfe リソースによる Teams/RBAC の宣言例（HCL）

resource "tfe_team" "ci" {
  name         = "ci-writers"
  organization = var.org

  # 必要な場合のみ組織レベル権限を限定付与
  organization_access {
    manage_workspaces   = true
    manage_variable_sets = true
  }
}

resource "tfe_project" "app" {
  name         = "app-project"
  organization = var.org
}

resource "tfe_workspace" "app_dev" {
  name         = "app-dev"
  organization = var.org
  project_id   = tfe_project.app.id
}

# プロジェクト全体に Write を付与（新規WSにも継承）
resource "tfe_team_project_access" "ci_app" {
  team_id    = tfe_team.ci.id
  project_id = tfe_project.app.id
  access     = "write"  # admin|write|read|plan(環境により)
}

# 例外: 特定WSのみ Plan に下げる（または上げる）
resource "tfe_team_access" "ci_app_dev_override" {
  team_id      = tfe_team.ci.id
  workspace_id = tfe_workspace.app_dev.id
  access       = "plan"
}

# チームトークン（CIに登録）
resource "tfe_team_token" "ci_token" {
  team_id = tfe_team.ci.id
}

output "ci_token" {
  value       = tfe_team_token.ci_token.token
  sensitive   = true
  description = "登録後は即時にマスク/ローテーション戦略を適用"
}

SSO/SCIM連携とチーム運用のベストプラクティス

ビジネスプラン相当の機能では、SAML SSO と SCIM によりIdPグループを Terraform Cloud の Teams にマッピングできます。入退社や組織変更のたびに手作業でチームメンバーを更新する負担を減らし、監査証跡も明確になります。

Owners の日常利用は避け、IdPグループをもとに「環境別（dev/stg/prod）」「職務別（運用/監査/プラットフォーム）」「プロダクト別」の3軸でチームを設計し、プロジェクトアクセスを既定に、ワークスペース個別で最小限上書きするパターンが扱いやすいです。

• IdP側グループ設計 = Terraform Cloud のチーム設計。命名規則を統一する。
• Owners は非常時のみ。日常の運用は管理者チーム（Admin）で代替する。
• SCIM 連携時は、IdPからの削除が即時に権限剥奪に反映されることを前提とした運用（ブレークグラス口座を別管理）。

チームメンバ管理のIaC化（SCIM未利用時の例）

resource "tfe_team" "ops" {
  name         = "ops-admins"
  organization = var.org
}

# メンバ明示（SCIM未導入時の暫定）
resource "tfe_team_members" "ops_members" {
  team_id = tfe_team.ops.id
  usernames = [
    "[email protected]",
    "[email protected]"
  ]
}

試験対策チェックリストと実務での落とし穴

試験では、権限の合成ロジック（最大権限が有効）、Owners と通常チームの違い、組織レベル権限がワークスペース実行権限を直接付与しない点、Plan 権限の性質（適用不可）あたりが頻出です。プロジェクトアクセスの継承と、個別ワークスペースでの上書きも押さえてください。

実務では、Admin の広範権限、Owners 常用、ユーザトークンのCI流用、プロジェクトアクセスの無差別Admin化、チームトークンの未ローテーションが典型的な事故要因です。変数セットやポリシーセットの管理も組織レベル権限が必要になる点を忘れがちです。

• 有効権限 = max(Project Access, Workspace Access)。
• Owners は例外的な強権。通常運用は避ける。
• Plan はApply不可。Write はApply可。Admin は設定変更/削除まで可能。
• 組織レベル権限（例: manage_variable_sets, manage_policies）はワークスペース実行権限とは別軸。
• 新規ワークスペースはプロジェクトアクセスを継承。例外は個別で付与/剥奪。

変数セット管理と付与の例（組織レベル権限が必要）

resource "tfe_variable_set" "shared" {
  name         = "shared-networking"
  organization = var.org

  variable {
    key         = "TF_VAR_region"
    value       = "us-east-1"
    category    = "env"
    description = "標準リージョン"
    sensitive   = false
  }
}

resource "tfe_variable_set_attachment" "attach_project" {
  variable_set_id = tfe_variable_set.shared.id
  project_id      = tfe_project.app.id
}

# 変数セットのCRUDには manage_variable_sets 等の組織権限が関与

問題で確認

よくある質問