[{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/blogs/","section":"Blogs","summary":"","title":"Blogs","type":"blogs"},{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/tags/hcp-terraform/","section":"Tags","summary":"","title":"HCP Terraform","type":"tags"},{"content":" はじめに 👋 # こんにちは、Nimbusです。\nHCP Terraformを大規模環境で運用してきた中で、 「これは落とし穴だ！」と感じた運用上の課題をTop5形式でまとめました。\nこれからHCP Terraformを本格導入する方、すでに運用中だけど何か引っかかっている方の 参考になれば幸いです。それでは、Let\u0026rsquo;s Dive in! 🦄\n落とし穴1：トークンの種類による権限の違いを知らない 🔑 # 何が起きたか # 「Private Module RegistryにModuleをpublishしようとしたら、権限エラーで失敗\u0026hellip;」\n実はこれ、私が実際に遭遇した問題です。Organization Tokenを使って Private Module Registryへのpublishを試みたのですが、何度やっても unauthorizedエラーが返ってきました。\n問題の本質 # HCP Terraformには3種類のトークンが存在しますが、それぞれできることが異なります：\nトークンの種類 用途 Private Module Registry publish Organization Token 組織全体の操作 ❌ できない Team Token チーム単位の操作 ✅ できる User Token 個人ユーザーの操作 ✅ できる 特に厄介なのが、Organization TokenではPrivate Module Registryへのpublishができないこと。 これはTeam TokenまたはUser Tokenでないと実行できません。\nUIからは問題なくpublishできたのに、Terraformから実行するとエラーになる\u0026hellip; この原因が「使っているトークンの種類」だと気づくまで、かなり時間を要しました。\n対策とベストプラクティス 💡 # 1. 用途に応じたトークンを使い分ける\n# Private Module Registry操作にはTeam Token provider \u0026#34;tfe\u0026#34; { token = var.team_token # Organization Tokenではなく } 2. トークンの管理ルールを明確にする\nチームトークンの作成は手作業で実施 発行したトークンはVariable SetsまたはHCP Vaultに保管 有効期限は90日として、ライフサイクルはチームで管理 3. ドキュメント化する 各トークンで「できること・できないこと」を表にまとめてチーム共有しましょう。\nHCP Terraform API Tokens 落とし穴2：VCS連携の見えない依存関係 🔗 # 何が起きたか # ある日、後輩から「VCSプロバイダーからいくつかのリポジトリが見えなくなった」と連絡がありました。\n状況整理：\n登場人物：私（GitHub OrganizationのOwner権限あり）と後輩（Owner権限なし） 最初にVCSプロバイダーを作成したのは私 作成直後は正常にOrganization内のリポジトリが確認できていた 後輩が何かのタイミングでVCSプロバイダーの再認証を実施 再認証後、いくつかのリポジトリが見えなくなった 問題の本質 # HCP TerraformのVCS連携は、個人のGitHubアカウントと密に紐付いている\nVCSプロバイダーを再認証した際、その操作を行ったユーザーのGitHub権限が VCSプロバイダーのアクセススコープに反映されます。\n最初の状態： VCSプロバイダー（私のOwner権限で作成） → Organization内の全リポジトリが見える ✅ 後輩が再認証後： VCSプロバイダー（後輩の権限で再認証） → 後輩がアクセスできるリポジトリのみ見える ⚠️ → Owner限定のリポジトリが見えなくなる ❌ Owner権限を持つ私のユーザーで再認証したら、すべて正常に戻りました。\n対策とベストプラクティス 💡 # 1. VCS接続の責任者を明確にする\n誰がVCSプロバイダーを管理するか文書化 再認証は必ず管理者権限を持つユーザーが実施 2. 専用アカウントの作成（推奨）\n私たちの組織では、個人アカウントに依存しない専用アカウントを作成しています：\n専用アカウント：terraform-admin@xxxxx.com 【HCP Terraform側】 - 専用メールアドレスでユーザー登録 - Organization Owner権限を付与 【GitHub側】 - 同じメールアドレスでGitHubアカウント作成 - Organization Owner権限を付与 - このアカウントでVCSプロバイダーを作成・管理 このアプローチのメリット：\n✅ 個人に依存しない（誰かが退職しても影響を受けない） ✅ 権限管理が明確（専用アカウントの権限のみ管理すればよい） ✅ 再認証時のリスク低減（常に同じ権限で再認証される） ✅ 監査が容易（VCS操作がすべてこのアカウント経由） 3. 定期的な権限確認\nVCSプロバイダーでアクセスできるリポジトリ一覧を定期的に確認 想定外のリポジトリが見えなくなっていないかチェック 専用アカウントの認証情報を安全に管理（パスワード管理ツールなど） 注意: 「再認証」は単なる認証更新ではなく、アクセススコープの再定義です！ 落とし穴3：WorkspaceのTerraform管理 - ガバナンス vs 利便性のジレンマ ⚖️ # 何が起きたか # 「Workspaceの設定を少し変えたいだけなのに、いちいち管理者に依頼しないといけない\u0026hellip;」 「自由に触らせたら、OIDC認証ではなくシークレットキーを直接入力された\u0026hellip;」\nWorkspaceをTerraformで管理するかどうかは、大規模運用では避けて通れない問題です。\n問題の本質 # アプローチ1：Terraformで厳格に管理 # ✅ メリット： - ガバナンスを効かせられる（OIDC強制、命名規則統一など） - 変更履歴がGitに残る - Policy as Codeで設定を強制 ❌ デメリット： - 利用者の自由度が低い - カスタマイズのたびに管理者へ依頼→ボトルネック化 - 「ちょっと試したい」ができない アプローチ2：利用者に自由に触らせる # ✅ メリット： - 開発速度が上がる - 管理者がボトルネックにならない - 柔軟なカスタマイズが可能 ❌ デメリット： - OIDC使わずシークレット直接入力される - 命名規則が守られない - セキュリティリスク増大 対策とベストプラクティス 💡 # 私たちの組織の選択：厳格にTerraformで管理\n私たちの組織では、組織の特性上、ガバナンスを優先し、すべてをTerraformで厳格に管理する方針を取っています。\n1. 基盤設定はすべてTerraformで管理\n# Workspace作成から設定まですべてコード化 resource \u0026#34;tfe_workspace\u0026#34; \u0026#34;example\u0026#34; { name = var.workspace_name organization = var.organization # VCS連携を設定 vcs_repo { identifier = var.repository oauth_token_id = var.oauth_token_id } } 2. Google Cloud認証はWorkload Identity（Dynamic Credentials）で統一\n私たちの環境ではGoogle Cloud Workload Identityを使った動的クレデンシャルを採用しています。 これにより、シークレットキーの直接入力を根本的に防ぐことができます。\n# Workload Identity Poolの設定 resource \u0026#34;google_iam_workload_identity_pool\u0026#34; \u0026#34;pool\u0026#34; { workload_identity_pool_id = \u0026#34;hcp-terraform-pool\u0026#34; display_name = \u0026#34;HCP Terraform Pool\u0026#34; description = \u0026#34;Pool for HCP Terraform workspaces\u0026#34; } # Workload Identity Providerの設定 resource \u0026#34;google_iam_workload_identity_pool_provider\u0026#34; \u0026#34;hcp_terraform\u0026#34; { workload_identity_pool_id = google_iam_workload_identity_pool.pool.workload_identity_pool_id workload_identity_pool_provider_id = \u0026#34;hcp-terraform-provider\u0026#34; display_name = \u0026#34;HCP Terraform Provider\u0026#34; oidc { issuer_uri = \u0026#34;https://app.terraform.io\u0026#34; } attribute_mapping = { \u0026#34;google.subject\u0026#34; = \u0026#34;assertion.sub\u0026#34; \u0026#34;attribute.terraform_workspace_id\u0026#34; = \u0026#34;assertion.terraform_workspace_id\u0026#34; \u0026#34;attribute.terraform_organization_id\u0026#34; = \u0026#34;assertion.terraform_organization_id\u0026#34; } } # サービスアカウントとの紐付け resource \u0026#34;google_service_account_iam_binding\u0026#34; \u0026#34;workload_identity\u0026#34; { service_account_id = google_service_account.terraform_sa.name role = \u0026#34;roles/iam.workloadIdentityUser\u0026#34; members = [ \u0026#34;principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.pool.name}/attribute.terraform_workspace_id/${var.workspace_id}\u0026#34; ] } 3. Variable Setsで認証情報を一元管理\n各WorkspaceにはVariable Setを通じてWorkload Identity設定を自動適用：\n# Variable Set作成 resource \u0026#34;tfe_variable_set\u0026#34; \u0026#34;gcp_workload_identity\u0026#34; { name = \u0026#34;gcp-workload-identity-credentials\u0026#34; description = \u0026#34;Google Cloud Workload Identity settings\u0026#34; organization = var.organization } # Workload Identity有効化フラグ resource \u0026#34;tfe_variable\u0026#34; \u0026#34;enable_gcp_provider_auth\u0026#34; { key = \u0026#34;TFC_GCP_PROVIDER_AUTH\u0026#34; value = \u0026#34;true\u0026#34; category = \u0026#34;env\u0026#34; variable_set_id = tfe_variable_set.gcp_workload_identity.id } # Workload Providerの指定 resource \u0026#34;tfe_variable\u0026#34; \u0026#34;workload_provider_name\u0026#34; { key = \u0026#34;TFC_GCP_WORKLOAD_PROVIDER_NAME\u0026#34; value = google_iam_workload_identity_pool_provider.hcp_terraform.name category = \u0026#34;env\u0026#34; variable_set_id = tfe_variable_set.gcp_workload_identity.id } # サービスアカウントの指定 resource \u0026#34;tfe_variable\u0026#34; \u0026#34;service_account_email\u0026#34; { key = \u0026#34;TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL\u0026#34; value = google_service_account.terraform_sa.email category = \u0026#34;env\u0026#34; variable_set_id = tfe_variable_set.gcp_workload_identity.id } このアプローチで実現できること：\n✅ シークレットキーの直接入力を防止（そもそもできない仕組み） ✅ 認証情報の一元管理（Variable Setで統一） ✅ セキュリティの強化（短期トークンを自動生成） ✅ 監査の容易化（誰がいつアクセスしたか追跡可能） ✅ 設定の標準化（すべての設定がコードとして履歴に残る） トレードオフ：得られたものと失ったもの\n正直に言うと、この厳格な管理にはデメリットもあります：\n✅ 得られたもの： - 強固なガバナンス体制 - 設定ミスの大幅な削減 - セキュリティの向上 - 変更履歴の完全な可視化 ❌ 失ったもの： - 開発者の自由度 → 変数の値をちょっと変えたいだけなのに管理者に依頼 → 通知設定の変更すら自分でできない - 開発スピード → 管理者がボトルネックになる → 「プロジェクト内だけでも自由にさせてほしい」という声 実際に開発者から聞いた声：\n「変数の値を更新するだけなのに、なぜPull Requestが必要なの？」 「通知設定くらい自分で変えさせてほしい\u0026hellip;」 「プロジェクト内の設定くらいは自由にさせてほしい」 これらの声は十分理解できます。しかし、私たちの組織では、組織の特性上、ガバナンスを優先せざるを得ないという判断をしています。\n組織によって優先順位は異なる\n重要なのは、どちらが正解というわけではないということです：\n優先事項 推奨アプローチ ガバナンス・監査対応が最優先 Terraformで厳格に管理 開発スピード・柔軟性が最優先 利用者に開放 両方のバランスを取りたい 段階的管理（重要な設定はTerraform、それ以外は開放） 私たちのように金融・小売・医療など規制の厳しい業界では、前者を選ばざるを得ないことが多いです。 一方、スタートアップや開発スピード重視の組織では、後者が適しているでしょう。\n判断のポイント：\n組織のコンプライアンス要件はどの程度厳しいか？ セキュリティインシデントが発生した場合の影響は？ 開発者の不便さと、ガバナンス強化、どちらを優先すべきか？ 管理者のリソースは十分にあるか？ ポイント: 完璧な解決策はありません。組織の特性に応じて、何を優先するかを明確にすることが重要です。 Dynamic Credentials with the Google Cloud Provider 落とし穴4：Workspace設計ミス - ライフサイクルの混在 🔄 # 何が起きたか # 「検証用のデータベースを削除したいのに、本番リソースと同じWorkspaceで管理してて消せない\u0026hellip;」 「不要なリソースが残り続けて、毎月無駄なコストが発生している\u0026hellip;」\n問題の本質 # ライフサイクルが異なるリソースを1つのWorkspaceに詰め込んでしまった\n❌ 悪い例： Workspace: myapp-prod ├─ 本番データベース（常時稼働・絶対に消せない） ├─ 検証用データベース（開発時のみ・消したい） └─ テスト用インスタンス（たまに使う・消したい） → 検証用だけ消したいのに、terraform destroyすると全部消える！ → 仕方なく放置...コストだけがかさむ これは単に「環境を分ける」だけでは解決しません。 同じ本番環境でも、常時稼働が必要なものと一時的なものは分離すべきです。\n対策とベストプラクティス 💡 # 正しい設計：Volatility（変動性）でグルーピング\n✅ 良い例： Workspace: myapp-prod-core └─ 本番データベース（常時稼働・変更頻度：低） Workspace: myapp-prod-testing └─ 検証用データベース（一時的・変更頻度：高） → 不要になったらWorkspaceごと削除可能！ Workspace: myapp-prod-temporary └─ テスト用インスタンス（スポット使用） → 使用後は即削除 Workspace設計の3つの軸：\nEnvironment（環境）: dev / staging / prod Lifecycle（ライフサイクル）: permanent / temporary / ephemeral Component（コンポーネント）: network / compute / data 具体的な命名規則：\n{プロジェクト}-{環境}-{ライフサイクル}-{コンポーネント} 例： - payment-prod-permanent-database - payment-prod-temporary-testing - payment-dev-ephemeral-sandbox コスト最適化のポイント: 一時的なリソースは専用Workspaceで管理し、使用後はWorkspaceごと削除！ さらに便利な機能：Automatically Destroy\nHCP Terraformには、一時的なWorkspace向けのAutomatically Destroy機能があります（プランによって利用可否が異なります）。\nresource \u0026#34;tfe_workspace\u0026#34; \u0026#34;temporary\u0026#34; { name = \u0026#34;myapp-prod-temporary\u0026#34; organization = var.organization # 自動削除の設定 auto_destroy_at = \u0026#34;2025-12-31T23:59:59Z\u0026#34; # 指定日時に自動destroy } この機能のメリット：\n✅ 削除忘れを防止（指定日時に自動的にterraform destroy実行） ✅ コスト削減の自動化（手動で削除する必要がない） ✅ 一時的な検証環境に最適（検証期間終了後、自動的にクリーンアップ） 使用例：\n検証用Workspace: myapp-prod-feature-test → auto_destroy_at: \u0026#34;2025-02-28T23:59:59Z\u0026#34;（2週間後に自動削除） → 検証終了後、自動的にリソースが削除される UIからも設定可能で、Workspace設定画面から「Auto-destroy」のスケジュールを設定できます。\nWorkspace Auto-Destroy 落とし穴5：Variable Setsのスコープがカオス化 📦 # 何が起きたか # 「あれ？この変数どのWorkspaceに適用されてるんだっけ\u0026hellip;？」 「本番環境なのに、開発用のGCP認証情報が適用されてる！」\n大規模運用になると、Variable Setsの管理が一気にカオス化します。\n問題の本質 # Variable Setが乱立し、誰も全体像を把握していない\nカオスの実例： Variable Set: gcp-credentials → 適用先：全Workspace（本番も開発も！）😱 Variable Set: gcp-prod-only → 適用先：なぜか開発環境のWorkspaceにも適用されている... Variable Set: common → 適用先：誰も把握していない → 中身：謎の変数が大量に入っている Variable Set: gcp-creds-prod Variable Set: gcp-credentials-production Variable Set: prod-gcp-auth → 全部同じ用途なのに命名がバラバラ... なぜこうなるか：\nVariable Setsの命名規則がない スコープ（どのWorkspaceに適用するか）の設計がない 個人が勝手にVariable Setを作成してしまう 不要になったVariable Setを削除していない 対策とベストプラクティス 💡 # 1. 命名規則を統一する\n{環境}-{プロバイダー}-{用途} 例： ✅ prod-gcp-credentials ✅ dev-gcp-service-account ✅ staging-gcp-workload-identity ✅ global-common-vars（全環境共通） 2. タグベースでスコープを制御\n# Workspaceにタグを付与 resource \u0026#34;tfe_workspace\u0026#34; \u0026#34;example\u0026#34; { name = \u0026#34;myapp-prod\u0026#34; organization = var.organization tags = { environment = \u0026#34;prod\u0026#34; cloud = \u0026#34;gcp\u0026#34; component = \u0026#34;api\u0026#34; } } # Variable Setはタグで適用範囲を指定 resource \u0026#34;tfe_variable_set\u0026#34; \u0026#34;prod_gcp\u0026#34; { name = \u0026#34;prod-gcp-credentials\u0026#34; organization = var.organization } # タグに基づいてVariable Setを適用 resource \u0026#34;tfe_workspace_variable_set\u0026#34; \u0026#34;prod_gcp_assignment\u0026#34; { for_each = { for ws in data.tfe_workspace_ids.prod_workspaces.ids : ws =\u0026gt; ws } workspace_id = each.value variable_set_id = tfe_variable_set.prod_gcp.id } data \u0026#34;tfe_workspace_ids\u0026#34; \u0026#34;prod_workspaces\u0026#34; { organization = var.organization tag_names = [\u0026#34;environment:prod\u0026#34;] } 3. Variable SetもTerraformで管理\n# IaCで管理することで： # - 誰が何を作ったか履歴に残る # - レビュープロセスを挟める # - 不要なVariable Setを検出しやすい resource \u0026#34;tfe_variable_set\u0026#34; \u0026#34;example\u0026#34; { name = var.variable_set_name description = var.description organization = var.organization } 4. 定期的な棚卸し\n月次でVariable Setの一覧を確認 使われていないVariable Setを削除 命名規則に従っていないものを修正 実装例：スコープ管理のマトリックス\nVariable Set名 適用タグ 対象Workspace数 用途 prod-gcp-credentials environment:prod, cloud:gcp 15 本番GCP認証 dev-gcp-credentials environment:dev, cloud:gcp 30 開発GCP認証 global-common-vars （全Workspace） 195 組織名など HCP Terraform Variable Sets まとめ 💡 # HCP Terraformは強力なツールですが、大規模運用になると様々な落とし穴があります。 今回紹介した5つの落とし穴を意識することで、より安全で効率的な運用が可能になります。\n運用の鉄則： # ✅ トークンの種類と権限を理解する\n用途に応じた適切なトークンを選択 管理ルールを明確にする ✅ VCS連携は組織アカウントで管理\n個人アカウントに依存しない 再認証の影響範囲を理解する ✅ ガバナンスと利便性のバランスを取る\nセキュリティは厳格に、開発効率は柔軟に Variable Setsで共通設定を強制 ✅ ライフサイクルでWorkspaceを分離\n常時稼働 vs 一時的で分ける コスト最適化につながる ✅ Variable Setsは命名規則とタグで管理\nカオス化を防ぐ仕組みを最初から作る 定期的な棚卸しを忘れずに おわりに ✨ # 大規模なHCP Terraform運用は試行錯誤の連続でした。 今回紹介した落とし穴は、すべて実際に遭遇し、痛い目を見た経験から学んだものです。\nこれらの経験が皆さんの運用改善に少しでも役立てば嬉しいです。\n「こんな落とし穴もあった！」というご意見や質問があれば、 ぜひコメントやSNSで教えてください。\nそれでは、また次回お会いしましょう！See ya 👋🏻\n","date":"2025年12月30日","externalUrl":null,"permalink":"/blogs/hcp-terraform-pitfalls-top5/","section":"Blogs","summary":"","title":"HCP Terraform運用の落とし穴トップ5","type":"blogs"},{"content":"技術ブログへようこそ! ここでは様々な技術テーマについて発信しています🚀\n","date":"2025年12月30日","externalUrl":null,"permalink":"/","section":"Nimbus の技術ブログへようこそ!","summary":"","title":"Nimbus の技術ブログへようこそ!","type":"page"},{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/tags/terraform/","section":"Tags","summary":"","title":"Terraform","type":"tags"},{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/tags/%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9/","section":"Tags","summary":"","title":"ベストプラクティス","type":"tags"},{"content":"","date":"2025年12月30日","externalUrl":null,"permalink":"/tags/%E9%81%8B%E7%94%A8/","section":"Tags","summary":"","title":"運用","type":"tags"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/gcp/","section":"Tags","summary":"","title":"GCP","type":"tags"},{"content":" はじめに 👋 # こんにちは、ニンバスです！\n現在、私は大規模なHCP Terraform環境の管理者として、組織全体で100以上のworkspaceを運用しています。\n特徴的なのは、複数の開発チーム（インフラ開発者）が同じHCP Terraform環境を共同利用しているという点です。それぞれのチームが独立してインフラを構築しつつ、組織全体のセキュリティやコスト要件を守る必要があります。\nこうした環境では、人によるレビューだけでガバナンス（統制）を効かせることには限界があります。そこで注目したのがPolicy as Codeという考え方、そしてHCP Terraformが提供するSentinel Policyです。\nこの記事では「Sentinelに興味を持ち始めた方」に向けて、導入前に知っておくべきことを実体験から共有します。それでは、Let\u0026rsquo;s Dive in! 🦄\nこの記事は実際の企業でのSentinel Policy導入プロジェクトを基にしていますが、社名や機密情報は伏せています。 なぜSentinelが必要だったのか 🎯 # 複数チーム環境特有の課題 # 私たちの組織では、HCP Terraformで100以上のworkspaceを管理しています。複数の開発チームが利用する環境では、いくつかの課題が顕在化しました。\n各チームは独自にPull Requestのレビューを行い、インフラ変更を進めています。私たちの管理チームにレビュー依頼が来ることはありません。つまり、各チーム内でレビューが完結する仕組みです。\nしかし、この仕組みには問題がありました。チームごとにレビュアーの知識や経験が異なるため、チェックの品質にばらつきが生じていたのです。あるチームでは厳格にセキュリティチェックが行われる一方で、別のチームでは見落としが発生してしまう。特に問題だったのは、ネットワークやアクセス制御に関する設定ミスです。意図せず広範囲へのアクセスを許可してしまうケースが何度かありました。\nさらに、「後で修正する」と言いつつ放置される問題も頻発していました。各チームのセキュリティ意識や知識レベルにばらつきがあり、「こういう設定にすべき」というルールが暗黙知化している状況でした。\n「このままではセキュリティインシデントが起きる」という危機感が、私たちをPolicy as Codeの導入へと駆り立てました。\nPolicy as Codeという解決策 # Policy as Codeとは、セキュリティやインフラのポリシー（ルール）をコードで表現し、自動的にチェック・強制する仕組みです。\n従来の方法では、ドキュメントでルールを定義し、人がレビューでチェックしていました。しかし、これでは見落としが発生し、ルール遵守が難しいという問題がありました。\nPolicy as Codeでは、ルールをコードで定義することで、機械が自動的にチェックします。つまり「ルールに違反しているコードは、そもそもApplyさせない」という強制力を持たせることができるのです。\nHCP Terraformが提供するSentinel機能を使えば、複数チームに対して一律のルールを自動適用できます。各チームのレビュー品質のばらつきを気にする必要がなくなります。\nSentinelとは？ 📘 # Policy as Codeの概念 # Policy as Codeには、いくつかの大きなメリットがあります。まず、人によるレビューに頼らず機械的にチェックできるため、完全な自動化が可能です。また、誰が実行しても同じ基準でチェックされるため、一貫性が保たれます。さらに、ポリシーがコードで可視化されるため透明性が高く、Gitで変更履歴を追跡できるためバージョン管理も容易です。\nSentinelとOPAの比較 # HCP Terraformでは、ポリシー言語としてSentinelとOPA（Open Policy Agent）の2つがサポートされています。\n項目 Sentinel OPA 開発元 HashiCorp CNCF 適用レベル 3段階 2段階 学習のしやすさ 比較的簡単 やや難しい なぜSentinelを選んだのか # 私たちはSentinelを選択しました。決め手は3段階の適用レベルです。\nAdvisoryは「推奨」レベルで、違反してもWarning（警告）のみが表示され、Applyは可能です。Soft Mandatoryは「承認があれば可」というレベルで、違反するとApplyが止まりますが、管理者が承認すればApply可能です。Hard Mandatoryは「例外なく必須」というレベルで、違反すると完全にApplyが止まり、承認も不可能です。\nこの柔軟性により、複数チーム環境での段階的な導入が可能になります。いきなり厳しいルールを強制するのではなく、まずは警告から始めて徐々に強化していくことができるのです。\nPolicy enforcement levels - HCP Terraform公式ドキュメント Policy Setsによる環境別ガバナンス設計 🏗️ # Policy Setsとは # HCP Terraformでは、複数のSentinelポリシーをPolicy Setsとしてグループ化し、Workspace単位で適用できます。\nしかし、「どう設計すべきか」のベストプラクティスはまだ確立されていません。 導入事例が少なく、試行錯誤しながら最適解を探る必要がありました。\n複数チーム環境での設計課題 # 複数の開発チームが利用する環境では、環境ごとに求められるガバナンスレベルが異なります：\n本番環境: 厳格なセキュリティチェックが必須（ビジネスインパクト大） ステージング環境: 本番に準じるチェック（検証環境として） 開発環境: 開発速度を重視、チェックは緩めに Policy開発環境: ポリシー自体をテストする環境 すべての環境に同じポリシーを適用すると\u0026hellip;\n本番環境：セキュリティが不十分なリスク 開発環境：厳しすぎて開発が止まる → 環境別にPolicy Setsを分ける必要がある\n私たちが辿り着いたPolicy Sets設計 # 試行錯誤の結果、以下の3つのPolicy Setsに落ち着きました：\n1. Production Policy Set（本番・ステージング環境用） # 適用ポリシー： - VPC Firewall Rule → Hard Mandatory（例外なく必須） - Cloud Run冗長性チェック → Soft Mandatory（承認があれば可） 適用先Workspace： - *-prod（本番環境） - *-stg（ステージング環境） 設計のポイント：\nクリティカルなセキュリティはHard Mandatory（例外なし） ビジネス要件に応じて調整が必要なものはSoft Mandatory 2. Development Policy Set（開発環境用） # 適用ポリシー： - VPC Firewall Rule → Advisory（警告のみ） - Cloud Run冗長性チェック → Advisory（警告のみ） 適用先Workspace： - *-dev（開発環境） 設計のポイント：\nすべてAdvisory（警告のみ、Applyは可能） 開発チームの開発速度を損なわない 違反を可視化し、意識向上を促す 3. Policy Development Set（ポリシー開発環境用） # 適用ポリシー： - テスト用の検証ポリシー 適用先Workspace： - sentinel-mock-generator など 設計のポイント：\nポリシー自体をテストするための環境 本番適用前の動作確認 Policy Sets設計のベストプラクティス（学んだこと） # 試行錯誤を通じて学んだ、Policy Sets設計のポイントをシェアします：\n1. タグベースでWorkspaceを識別する # Workspace命名規則だけに頼るのではなく、タグを活用することで、より柔軟で管理しやすい設計になります。\n私たちの実装例：\nWorkspaceにタグを設定： - env:prod（本番環境） - env:stg（ステージング環境） - env:dev（開発環境） Policy Setsのスコープ設定：\nProduction Policy Set → env:prod、env:stgタグを持つWorkspaceに適用 Development Policy Set → env:devタグを持つWorkspaceに適用 タグベースのメリット：\nタグを使うことで、Workspace名の命名規則に依存しない柔軟な設計が可能になります。例えば、myapp-network-prodでもlegacy-system-productionでも、env:prodタグさえ付いていれば同じPolicy Setが適用されます。\nまた、ProjectやWorkspaceが増えても、タグを設定するだけで自動的にPolicy Setのスコープに含まれます。手動でWorkspaceを一つ一つ追加する必要がありません。\nさらに重要なのは、Policy SetsのスコープをTerraformで管理しているという点です。特定のタグを持つWorkspaceを一括で取得し、対象のWorkspaceを自動でスコープに追加することができます。つまり、Workspaceが100個から200個に増えても、コードを変更する必要がないのです。\nTerraformでの実装イメージ：\n# 特定のタグを持つWorkspaceを取得 data \u0026#34;tfe_workspace_ids\u0026#34; \u0026#34;prod_workspaces\u0026#34; { tag_names = [\u0026#34;env:prod\u0026#34;] organization = var.organization_name } # Policy Setにスコープを設定 resource \u0026#34;tfe_policy_set\u0026#34; \u0026#34;production\u0026#34; { name = \u0026#34;production-policy-set\u0026#34; organization = var.organization_name # タグで取得したWorkspaceを自動で適用 workspace_ids = data.tfe_workspace_ids.prod_workspaces.ids # ポリシーファイルをVCSから取得 vcs_repo { identifier = \u0026#34;your-org/hcp-terraform-policies\u0026#34; branch = \u0026#34;main\u0026#34; } } この設計により、インフラのスケールに対応できる仕組みが実現できました。\n2. ポリシーは共通、適用レベルだけを変える # 最初は「本番用ポリシー」「開発用ポリシー」を別々に作ろうとしましたが、メンテナンスが二重になる問題に気づきました。\nベストプラクティス：\nポリシーコード自体は同じものを使う Policy Setsごとに適用レベル（Hard/Soft/Advisory）だけを変える 例：\nVPC Firewall Ruleポリシー（コードは共通） → Production Policy Set：Hard Mandatory → Development Policy Set：Advisory 3. 段階的な移行パスを設計する # 新しいポリシーを追加する際の推奨フロー：\nSTEP 1: Development Policy SetにAdvisoryで追加 ↓（開発チームからフィードバック収集） STEP 2: ポリシーを調整・改善 ↓（問題なければ） STEP 3: Production Policy SetにAdvisoryで追加 ↓（本番環境で様子見） STEP 4: Soft Mandatory → Hard Mandatoryへ段階的に強化 → いきなり本番環境でHard Mandatoryにしない\n4. Policy SetsをTerraformで管理する # Policy Sets自体もInfrastructure as Codeとして管理します。私たちはHCP TerraformのPolicy SetsをTerraformで定義・管理しています。\n具体的には、ポリシーコードをGitHubで管理し、HCP TerraformとVCS連携します。Policy Setのリソース定義（どのWorkspaceに適用するか、どのポリシーファイルを使うかなど）もTerraformコードで記述します。\nこの方法のメリットは非常に大きいです。まず、Policy Setの変更をPull Requestでレビューできるため、チーム全体で変更内容を確認できます。変更履歴もGitで追跡可能なため、「誰が、いつ、なぜ変更したか」が明確です。\nさらに、前述のタグベースのスコープ設定と組み合わせることで、ProjectやWorkspaceが増えてもPolicy Setのコードを変更する必要がありません。新しいWorkspaceに適切なタグ（例：env:prod）を設定するだけで、自動的に対象のPolicy Setが適用されます。\nロールバック（元に戻す）も容易です。Terraformの状態管理により、以前のバージョンに戻すことができます。\n5. HCP Terraform利用者への周知を忘れない # Policy Setsを更新したら、必ず開発チーム（HCP Terraform利用者）に周知します：\n何が変わったか なぜ変更したか いつから適用されるか 特に重要：\nAdvisoryからSoft/Hard Mandatoryに変更する際は事前告知 開発チームが対応する時間を確保 Policy Sets導入で期待できる効果 # 環境別Policy Sets設計により、以下の効果が期待できます：\n✅ 本番環境のセキュリティ向上\nクリティカルなルール違反を自動でブロックできるため、各チームのレビュー品質のばらつきに関わらず、組織全体で統一されたセキュリティ基準を維持できます。\n✅ 開発環境の柔軟性維持\nAdvisoryにより、開発チームの開発速度を損なうことなく、違反を可視化して意識向上を促すことができます。警告は出るが作業は止まらない、というバランスが重要です。\n✅ 段階的なガバナンス強化\n開発環境でAdvisoryとして試してから本番環境へ展開し、徐々にSoft Mandatory、Hard Mandatoryへと強化していく道筋が描けます。開発チームの混乱を最小限に抑えながら、組織全体のガバナンスを強化できます。\nManaging Policy Sets - HCP Terraform公式ドキュメント Sentinel導入の最初の壁 😰 # 「何をポリシー化すべきか」が定まらない # Sentinelポリシー開発を始めようと意気込んだものの、肝心の**「何をチェックすべきか」が定まらない**という問題に直面しました。\n背景：\n組織内にCCoE（Cloud Center of Excellence）チームが存在 CCoEチームと「クラウド利用ルール」をすり合わせる必要があった しかし、CCoEチームも発足したばかりで稼働が取れない状況 試行錯誤のプロセス：\nこちらから草案を提示 - 待っていても進まないため、私たちから草案を提示 「ああだ、こうだ」の繰り返し - CCoEチームとのMTGで議論するも決着せず 先行実装の決断 - 「ポリシー化できそうなもの」から先行着手 気づき：小さく始めることの重要性\nすべてを決める必要はない ビジネス要件が明確なものから着手 フィードバックを得ながら改善 最初のポリシー選定のポイント 🔑 # どのポリシーから始めるべきか # 「何をポリシー化すべきか」が定まらない中で、私たちはビジネス要件が明確なものから着手することにしました。\n最初のポリシーとして選んだのは、セキュリティ要件が高い環境でのネットワーク制御に関するルールでした。なぜこれを選んだのか、いくつか理由があります。\nまず、セキュリティ要件が明確だったことです。「外部への通信を制御する」という要件は、ビジネス上の必要性がはっきりしており、CCoEチームとも合意が取りやすいテーマでした。\n次に、チーム間で共通のニーズがあったことです。複数の開発チームがセキュリティ要件の高い環境を扱っており、全員に関係するルールでした。\nそして、ビジネスインパクトが大きかったことです。設定ミスによるデータ流出や不正なアクセスは、組織にとって重大なインシデントにつながります。「後で直す」では済まされない領域でした。\nAdvisory適用レベルを選んだ理由 # 最初のポリシーには、Advisory（推奨）適用レベルを選択しました。これは戦略的な判断です。\nまず、認知フェーズを重視しました。いきなり厳しいルールを強制するのではなく、「Policy as Codeを実践している」ことを開発チームに知ってもらうことが先決でした。開発チームの混乱を避け、スムーズに受け入れてもらうことを優先したのです。\n次に、フィードバック収集を目的としました。実運用でポリシーの妥当性を検証する必要がありました。「このチェックは厳しすぎる」「この条件だと開発が進まない」といった意見を吸い上げ、ポリシーを改善したかったのです。\nそして、段階的な強化計画を見据えていました。Advisory → Soft Mandatory → Hard Mandatoryと段階的に強化する道筋を描いていました。いきなりHard Mandatoryで強制すると、開発が止まるリスクがあります。\n現在の状況\n現在、すべてのポリシーをAdvisory適用レベルで運用しています。これは組織への「認知フェーズ」と位置づけているためです。開発チームの理解が深まった段階で、クリティカルなセキュリティ要件からSoft Mandatory、Hard Mandatoryへと段階的に強化していく計画です。\n導入で期待できる効果 📊 # 現在、私たちは導入フェーズにありますが、Sentinel Policyの導入により以下のような効果が期待できます。\n効果1：自動チェックの威力 # Pull Requestに自動でチェック結果がコメントされることで、開発チーム自身が違反に気づけるようになります。これにより、各チームのレビュアーの負担が軽減され、レビュー品質のばらつきも解消されることが期待できます。\n効果2：開発チームの意識変化 # ポリシー違反が可視化されることで、「後で直す」という先送りが減り、セキュリティへの意識が向上すると考えています。チーム間で統一された基準が明示されるため、暗黙知だったルールが明文化されます。\n効果3：継続的な改善サイクル # ビジネス要件は変化します。ポリシー自体もコードとして管理することで、開発チームからのフィードバックを反映しながら継続的に改善できます。TerraformでPolicy Setsを管理しているため、変更も容易です。\nSentinel導入を検討している方へ 🚀 # 始める前に準備すべきこと # ステークホルダー（関係者）との合意形成\nなぜPolicy as Codeが必要か どんなルールをポリシー化すべきか 小さく始める計画\nすべてを一度に実装しない ビジネス要件が明確なものから 段階的導入戦略\n最初はAdvisory適用レベル フィードバックを得ながら強化 特に複数チーム環境では # 認知フェーズを大切に\nいきなり強制しない 「なぜこのチェックが必要か」を丁寧に説明 フィードバックループを回す\n現場の声を聞く ポリシーを柔軟に調整 チーム全員が理解者になる必要はない\nまずは1-2名が理解すればOK 徐々に広げる まとめ 🎉 # Sentinel導入で学んだこと # 完璧を求めない - 小さく始めて段階的に Advisory戦略 - 強制ではなく啓蒙から 関係者との対話 - ルール策定は一人では決められない 継続的な改善 - ポリシーは一度作って終わりではない 複数チーム環境での価値 # Policy as Codeは、複数チームが協働する環境でこそ真価を発揮します。\n次のステップ # もしあなたがSentinelに興味を持ったなら\nHashiCorp公式ドキュメントを読む 小さなポリシーを1つ作ってみる Advisory適用レベルで試してみる この記事が参考になったら、是非SNSでシェアしてください！Sentinel Policyにより、皆さんの組織のガバナンス強化が実現することを願っています ✨\n","date":"2025年12月28日","externalUrl":null,"permalink":"/blogs/hcp-terraform-sentinel-policy-governance/","section":"Blogs","summary":"","title":"HCP Terraform Sentinel Policyを始める前に知っておきたいこと","type":"blogs"},{"content":" はじめに 👋 # こんにちは、ニンバスです！\n現在、私は大規模なHCP Terraform環境の管理者として、組織全体で100以上のworkspaceを運用しています。\nHCP Terraformを使い始めたとき、多くの方が最初に直面するのが「チーム・権限管理をどうするか」という問題です。最初は数人、数個のワークスペースだったものが、気づけば数十人、数百のワークスペースに成長していきます。\nそのとき、チーム・権限の設計を適当にやっていると、確実にカオスになります。\nこの記事では、カオスな状態から脱却した私たちの経験をもとに、これからHCP Terraformを本格導入する方が最初から正しく設計するためのベストプラクティスを共有します。それでは、Let\u0026rsquo;s Dive in! 🦄\nこの記事は実際の企業でのHCP Terraform運用経験を基にしていますが、社名や機密情報は伏せています。 なぜチーム・権限管理でカオスになるのか 🎯 # 私が見たカオスな現場 # 私が組織に参加する前の状態は、まさにカオスでした：\n「誰が、どんな権限を持っているのか」が誰も把握していない 強い権限を持ったメンバーが好き勝手にワークスペースを作成・変更 退職者のアカウントが削除されず残ったまま 本番環境に開発者が直接アクセスできる状態 チーム名が統一されていない（developers, team-a, prod-usersなど） すべて手動で管理されており、変更履歴もなく、Organization Ownerが10名以上という状態でした。\n放置すると起きる4つの問題 # 1. セキュリティリスク\n本番環境への不適切なアクセス、必要以上の権限を持つユーザーの存在、退職者アカウントの削除漏れなど、セキュリティ上の重大なリスクが生まれます。\n2. 運用負荷の増大\n「このワークスペースにアクセスしたい」という依頼が日常的に発生し、都度手動で権限を付与・調整する必要があります。誰がどこにアクセスできるか調べるだけで時間がかかります。\n3. 監査対応の困難さ\n「誰が、いつ、何にアクセスしたか」が追跡できず、コンプライアンス監査で苦労します。\n4. チーム間の混乱\n「なぜこのワークスペースにアクセスできないのか」「間違って本番環境を変更してしまった」といったトラブルが頻発します。\n「最初から正しく設計する」ことの価値 # 後から修正するのは大変です。100以上のワークスペース、数十人のユーザーがいる状態での権限整理は、想像以上に労力がかかります。\n最初からきちんと設計しておけば：\nセキュリティリスクを最小化できる 運用負荷が劇的に下がる チームが安心して開発できる スケールしても破綻しない 成功するチーム設計の4つの原則 🏗️ # 私たちが試行錯誤の末に辿り着いた設計原則を紹介します。\n原則1：ロールベースでチームを分ける # 環境（本番/ステージング/開発）と役割（管理者/開発者/閲覧者）の組み合わせでチームを構成します。\nなぜこの原則が重要か：\n環境ごとに求められるセキュリティレベルが異なる 役割ごとに必要な権限が異なる この2軸で分けることで、権限の過不足が発生しにくい 原則2：最小権限の原則を守る # 必要最小限の権限のみを付与し、過剰な権限は与えません。\n具体例：\n開発者は開発環境でPlan/Apply可能だが、本番環境は閲覧のみ 本番環境の管理者でも、Organization全体の設定は変更不可 閲覧者はPlan結果を見られるが、Apply実行は不可 原則3：チームベースで管理する # 個人に直接権限を付与せず、すべてチーム経由で管理します。\nメリット：\n新メンバー追加時、該当チームに追加するだけ 権限の棚卸しがチーム単位で可能 「このチームに所属している人は〇〇ができる」が明確 原則4：命名規則を統一する # チーム名から「何ができるか」が一目で分かるようにします。\n推奨命名規則：\n{システム名}-{レイヤー}-{環境名}-{役割} 具体例：\nsystemA-network-prod-admin - System Aのネットワーク本番環境管理者 systemA-security-stg-developer - System Aのセキュリティステージング環境開発者 systemA-app-dev-developer - System Aのアプリケーション開発環境開発者 systemA-db-prod-viewer - System Aのデータベース本番環境閲覧者 platform-infra-admin - プラットフォーム基盤管理者 この命名規則により、チーム名を見ただけで「どのシステムの、どのレイヤーの、どの環境で、何ができるか」が理解できます。\nレイヤーとは： 同じシステムでも、インフラチーム、セキュリティチーム、アプリケーションチーム、データベースチームなど、担当領域（レイヤー）が異なります。各チームは自分の担当するWorkspaceのみにアクセスできるよう、レイヤーごとにチームを分けます。\n実際の設計例 # 環境別 × レイヤー別 × 役割別のチーム構成 # 【本番環境チーム】 ├─ systemA-network-prod-admin（ネットワーク本番環境管理者） │ ✓ systemA-network-prod Workspaceの管理権限 │ ✓ Plan \u0026amp; Apply実行権限 │ ├─ systemA-security-prod-admin（セキュリティ本番環境管理者） │ ✓ systemA-security-prod Workspaceの管理権限 │ ✓ Plan \u0026amp; Apply実行権限 │ ├─ systemA-app-prod-admin（アプリケーション本番環境管理者） │ ✓ systemA-app-prod Workspaceの管理権限 │ ✓ Plan \u0026amp; Apply実行権限 │ └─ systemA-db-prod-viewer（データベース本番環境閲覧者） ✓ systemA-db-prod Workspaceの閲覧のみ ✗ Apply実行不可 【ステージング環境チーム】 ├─ systemA-network-stg-developer（ネットワークステージング開発者） │ ✓ systemA-network-stg Workspaceで開発 │ └─ systemA-app-stg-developer（アプリケーションステージング開発者） ✓ systemA-app-stg Workspaceで開発 【開発環境チーム】 ├─ systemA-network-dev-developer（ネットワーク開発環境開発者） │ ✓ systemA-network-dev Workspaceで開発 │ ✓ Workspace作成権限（開発環境のみ） │ └─ systemA-app-dev-developer（アプリケーション開発環境開発者） ✓ systemA-app-dev Workspaceで開発 ✓ Workspace作成権限（開発環境のみ） 【プラットフォーム管理チーム】 └─ platform-infra-admin（HCP Terraform管理者） ✓ Organization全体の管理 ✓ Team・User管理 ✓ Policy Sets管理 レイヤー別にチームを分けるメリット：\n同じSystem Aを担当していても、インフラチーム（network）、セキュリティチーム（security）、アプリケーションチーム（app）、データベースチーム（db）では、担当するWorkspaceが異なります。\nレイヤー別にチームを分けることで：\nインフラチームはsystemA-network-* Workspaceのみアクセス アプリチームはsystemA-app-* Workspaceのみアクセス セキュリティチームはsystemA-security-* Workspaceのみアクセス このように責任の境界線が明確になり、誤って他チームのWorkspaceを変更するリスクがなくなります。\n権限マトリックス # 実際の権限設計を表にまとめると以下のようになります：\nチーム Organization Project Workspace 備考 platform-infra-admin Manage Settings Admin Admin Platform管理者のみ（2-3名） systemA-network-prod-admin - Write Write ネットワーク本番環境管理者 systemA-security-prod-admin - Write Write セキュリティ本番環境管理者 systemA-app-prod-viewer - Read Read アプリケーション本番環境閲覧者 systemA-network-stg-developer - Write Write ネットワークステージング開発者 systemA-app-dev-developer - Write Write アプリケーション開発環境開発者 このマトリックスをドキュメント化しておくことで、新メンバーのオンボーディングや監査対応がスムーズになります。\nProject × Workspace × Team のマッピング # 実際の構成例：\nOrganization ├─ Project: system-A-prod │ ├─ Workspace: systemA-network-prod │ │ ↑ │ │ └─ Team: systemA-network-prod-admin (Write) │ │ │ ├─ Workspace: systemA-security-prod │ │ ↑ │ │ └─ Team: systemA-security-prod-admin (Write) │ │ │ ├─ Workspace: systemA-db-prod │ │ ↑ │ │ └─ Team: systemA-db-prod-viewer (Read) │ │ │ └─ Workspace: systemA-app-prod │ ↑ │ └─ Team: systemA-app-prod-admin (Write) │ ├─ Project: system-A-stg │ ├─ Workspace: systemA-network-stg │ │ ↑ │ │ └─ Team: systemA-network-stg-developer (Write) │ │ │ └─ Workspace: systemA-app-stg │ ↑ │ └─ Team: systemA-app-stg-developer (Write) │ └─ Project: system-A-dev ├─ Workspace: systemA-network-dev │ ↑ │ └─ Team: systemA-network-dev-developer (Write) │ └─ Workspace: systemA-app-dev ↑ └─ Team: systemA-app-dev-developer (Write) この構成のメリット：\n環境ごとにProjectを分けることで、Project-level権限で環境全体を制御できます。\nさらに、レイヤー（network, security, db, app）ごとにチームを分けることで、各チームは自分の担当Workspaceのみにアクセスできます。例えば：\nインフラチーム（network）はsystemA-network-* Workspaceのみ アプリチーム（app）はsystemA-app-* Workspaceのみ これにより、誤って他チームのWorkspaceを変更するリスクがなくなり、責任の境界線が明確になります。\nTerraformでチーム管理を「コード化」する 🔧 # なぜTerraformで管理すべきか # 手動でチーム・権限を管理していると、変更履歴が残らず、誰が何を変更したか分かりません。レビュープロセスもなく、設定ミスに気づきにくい状態です。\nTerraformでTeam管理を行う4つのメリット：\n✅ 変更履歴の完全な追跡 - すべての変更がGitで履歴管理される\n✅ レビュープロセスの導入 - Pull Requestでレビューを経てから反映\n✅ 宣言的な管理 - 「あるべき姿」をコードで定義\n✅ テンプレート化・自動化 - 新しいシステム追加時に再利用可能\n実装例 # 基本的なパターンは以下の通りです：\n# チーム定義 resource \u0026#34;tfe_team\u0026#34; \u0026#34;network_prod_admin\u0026#34; { name = \u0026#34;systemA-network-prod-admin\u0026#34; organization = var.organization_name organization_access { manage_policies = false manage_workspaces = false manage_vcs_settings = false } } # プロジェクトレベルの権限付与 resource \u0026#34;tfe_team_project_access\u0026#34; \u0026#34;network_prod_admin_access\u0026#34; { team_id = tfe_team.network_prod_admin.id project_id = tfe_project.system_a_prod.id # system-A-prod Project access = \u0026#34;write\u0026#34; } # ワークスペースレベルの権限付与 resource \u0026#34;tfe_team_access\u0026#34; \u0026#34;network_prod_admin_workspace\u0026#34; { team_id = tfe_team.network_prod_admin.id workspace_id = tfe_workspace.systemA_network_prod.id permissions { runs = \u0026#34;apply\u0026#34; variables = \u0026#34;write\u0026#34; state_versions = \u0026#34;write\u0026#34; workspace_locking = true } } このパターンを応用すれば、どんな規模のチーム・権限管理もコード化できます。\n詳しい実装方法は、HashiCorp公式ドキュメントのTerraform Provider - tfe_teamを参照してください。 運用を成功させる3つの実践 🌟 # 設計と実装ができたら、次は運用です。長期的に安定した運用を続けるための3つの実践を紹介します。\n1. SSO連携で入退社を自動化 # 私たちはEntra ID（旧Azure AD）とSSO連携しています。\nメリット：\n組織のIDプロバイダーと一元管理 入社時：自動的にHCP Terraformのチームに同期 退社時：HCP Terraformへのアクセスも自動で無効化 多要素認証（MFA）の強制が可能 IDプロバイダー側でのグループとHCP TerraformのTeamをマッピングすることで、権限管理の自動化が実現します。\n環境分離が必要な場合：\nセキュリティ要件が厳しい組織では、1人のユーザーが複数環境に簡単にアクセスできることを好まない場合があります。このような場合、環境ごとにアカウントを分離する選択肢もあります。\n例：\nuser-prod@example.com → 本番環境のみ user-stg@example.com → ステージング環境のみ user-dev@example.com → 開発環境のみ この方法では、本番環境にアクセスするには本番用アカウントでログインする必要があるため、「うっかり本番を触ってしまう」リスクを物理的に排除できます。アカウント管理は煩雑になりますが、金融・医療など本番環境への変更がクリティカルな組織では有効なアプローチです。\n2. Organization Ownerは2-3名に限定 # Organization Ownerは組織の削除、課金情報の変更、SSO設定の変更など、最も強い権限を持ちます。\n推奨：\nOrganization Ownerは2-3名のみに限定 それ以外の管理者は、Teamベースで必要な権限のみ付与 定期的に見直し、本当に必要な人だけに絞る 3. 四半期ごとの権限棚卸し # 権限は時間とともに「腐敗」します。定期的な見直しが重要です。\n四半期ごとに確認すべきこと：\n退職者・異動者のアカウント削除、各チームのメンバーが適切か確認、不要なチームの統廃合、過剰な権限を持つユーザーがいないか確認、Organization Ownerの数が適切かの確認を行います。\nTerraform管理のメリット： Gitの履歴を見れば、誰がいつ追加されたかすぐに分かります。\n# 特定のチームの変更履歴を確認 git log -p -- teams.tf | grep \u0026#34;prod-admin\u0026#34; これから始めるあなたへ 🚀 # 最初の一歩 # HCP Terraformを本格導入する際、以下のステップで進めることをお勧めします：\nSTEP 1: 設計原則を決める（1-2日）\n環境の区分（prod/stg/dev）、レイヤーの区分（network/security/app/db）、役割の区分（admin/developer/viewer）を決め、命名規則を統一します。SSO連携の有無も検討してください。\nSTEP 2: 小さく始める（1週間）\nまずは1つのシステム・プロジェクトから始めます。Terraformでチーム管理の基本パターンを実装し、ドキュメント（チーム構成図、権限マトリックス）を作成します。\nSTEP 3: 段階的に拡大（2-4週間）\n他のシステムにも展開し、Terraformコードをテンプレート化します。SSO連携を有効化し、定期的な棚卸しルールを決めます。\n特に大規模環境で気をつけること # 100+ Workspaces、複数チームでの運用では、以下が特に重要です：\n自動化は必須\n手動では追いつかなくなります。Terraformでの管理を最初から導入してください。\n命名規則の徹底\n統一された命名規則がないと、カオスになります。最初に決めて、徹底的に守りましょう。\n定期的な見直しの習慣化\n四半期ごとの棚卸しを、カレンダーに入れて確実に実施してください。\n段階的な権限昇格\n開発者は開発環境から始め、必要に応じて段階的にステージング・本番環境へアクセスできるようにします。\nまとめ 💡 # HCP Terraformのチーム・権限管理で押さえるべき4つのポイント：\n1. チームベースで管理 - 個人に直接権限を付与せず、すべてチーム経由で\n2. 最小権限の原則 - 必要最小限の権限のみを付与\n3. Terraformで管理 - 変更履歴、レビュープロセスのメリットを享受\n4. 定期的な見直し - 四半期ごとの権限棚卸しを習慣化\nチーム・権限設計は、HCP Terraform運用の基盤です。最初は面倒に感じるかもしれませんが、きちんと設計しておくことで、長期的な運用が格段に楽になります。\nこの記事が、これからHCP Terraformを本格導入する方の参考になれば幸いです！\n参考リンク：\nHCP Terraform Documentation - Teams HCP Terraform Documentation - Permissions Terraform Provider - tfe_team この記事が参考になったら、是非SNSでシェアしてください！HCP Terraformのチーム・権限設計により、皆さんの組織のガバナンス強化が実現することを願っています ✨\n","date":"2025年12月28日","externalUrl":null,"permalink":"/blogs/hcp-terraform-team-management/","section":"Blogs","summary":"","title":"HCP Terraformのチーム・権限管理で失敗しないために","type":"blogs"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/policy-as-code/","section":"Tags","summary":"","title":"Policy as Code","type":"tags"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/sentinel/","section":"Tags","summary":"","title":"Sentinel","type":"tags"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/%E3%83%81%E3%83%BC%E3%83%A0%E7%AE%A1%E7%90%86/","section":"Tags","summary":"","title":"チーム管理","type":"tags"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/%E3%82%AC%E3%83%90%E3%83%8A%E3%83%B3%E3%82%B9/","section":"Tags","summary":"","title":"ガバナンス","type":"tags"},{"content":"","date":"2025年12月28日","externalUrl":null,"permalink":"/tags/%E6%A8%A9%E9%99%90%E7%AE%A1%E7%90%86/","section":"Tags","summary":"","title":"権限管理","type":"tags"},{"content":" はじめに 👋 # こんにちは、ニンバスです！最近、コミュニティ版 Terraform から HCP Terraform への移行を支援するプロジェクトにいくつか携わることがありました。私はそれらのプロジェクトを通して、HCP Terraform の Workspace をうまく管理できているプロジェクトと、そうで無いプロジェクトには明確な違いがあるなと感じました。それが Workspace の設計方法です。\n実は HCP Terraform には Workspace 設計のベストプラクティスがあることをご存知ですか？今回は「HCP Terraform Workspace のベストプラクティス」について触れていきたいと思います。この記事を読んで、Workspace 設計のポイントを押さえてもらえたら嬉しいです。それでは、Let\u0026rsquo;s Dive in! 🦄\nWorkspace の設計で失敗しがちなパターン 😅 # まずは、よくある失敗パターンから見ていきましょう。私が実際に現場で見かけることが多いのは、以下のような構成です。\n❌ 失敗パターン # Organization: ${organization-name} └── Project: ${system-name} ├── ${system-name}-dev ├── ${system-name}-stage └── ${system-name}-prod 一見シンプルで分かりやすそうに見えます。しかし、実際は管理対象リソースが多すぎて管理しづらいケースもあります。\nHCP Terraform の各 Workspace は単一の状態ファイルを管理し、状態ファイルはその Workspace が管理するリソースの集合体になります。Workspace 上で管理するインフラリソースが多いほど管理は複雑になります。\n例えば、ただ単純に一つのリソースを変更したいだけなのに、Apply時には他のリソースにまで影響を与えてしまうケースもあります。必要最小限の変更を加えるためには、こういうケースはなるべく避けるべきです。\nまた、ある組織ではインフラチームが完全に Terraform を管理する（開発・運用保守する）こともあれば、ある組織では、セキュリティチーム、ネットワークチーム、アプリケーションチームとチームごとに Terraform を管理することもあります。\n上記の構成だと、「責任の境界線」がないので、複数チームで Terraform を管理する場合には少しやりづらさがあると思います。\n例えば：\nネットワークチームがVPCの設定を変更したいが、アプリケーションリソースも同じ Workspace にある アプリケーションチームがECSのタスク数を調整したいが、データベース設定も含まれるため慎重になる必要がある セキュリティチームがIAMポリシーを更新したいが、他チームの変更と競合する可能性がある Workspace の設計で成功しているパターン 😎 # ⭕️ 成功パターン # 次は、成功パターンから見ていきましょう。私が実際に現場で見て成功しているように思えたのは、以下のような構成です。 (後述している「HashiCorp 公式のベストプラクティス」に限りなく近い構成になっていると思います。)\nOrganization: ${organization-name} └── Project: ${system-name}-dev-pj | ├── Workspace: ${system-name}-network-dev | ├── Workspace: ${system-name}-security-dev | ├── Workspace: ${system-name}-database-dev | └── Workspace: ${system-name}-app-dev └── Project: ${system-name}-stg-pj | ├── Workspace: ${system-name}-network-stg | ├── Workspace: ${system-name}-security-stg | ├── Workspace: ${system-name}-database-stg | └── Workspace: ${system-name}-app-stg └── Project: ${system-name}-prod-pj ├── Workspace: ${system-name}-network-prod ├── Workspace: ${system-name}-security-prod ├── Workspace: ${system-name}-database-prod └── Workspace: ${system-name}-app-prod Workspace 名から見てわかるように「責任の境界線」が明確になっています。これにより「どのチームが、どの Workspace を管理するか」を決めやすくなり、Terraform コードおよび Workspace の管理も容易になります。\nHashiCorp 公式のベストプラクティス 🎯 # HashiCorp公式ドキュメントでは、以下の原則に基づいた Workspace 設計を推奨しています。これらの原則を実践することで、より安全で効率的な HCP Terraform 運用が実現できます。（以下、公式ドキュメントを参考に筆者が翻訳・編集）\nBest Practices - Workspaces 1. 小さな影響範囲を保つ # HCP Terraform Workspace は、単一のステートファイルとそのリソースのライフサイクルを管理します。これは、HCP Terraform で管理されるインフラストラクチャの最小単位です。リソースに対する操作は、同じステートファイルで管理される他のリソースに影響を与える可能性があります。そのため、操作の影響範囲をできるだけ小さく保つことが望ましいです。これを行うには、可能な限りリソースを別々の Workspace で管理し、必要かつ論理的に関連するリソースのみをグループ化してください。例えば、アプリケーションがコンピューティングリソースとデータベースの両方を必要とする場合でも、これらのリソースは独立して動作するため、それぞれ独自の Workspace に配置すべきです。HCP TerraformとTerraform Enterpriseの採用初期段階で、構成の範囲を明確化し、 Workspace 戦略を計画することで、運用を簡素化し、安全性を高めることができます。\n2. 公式推奨の命名規則 # 以下の命名規則を使用することをおすすめします。これにより、 Workspace をインフラストラクチャの特定のコンポーネントと関連付けて識別できます:\n${ビジネスユニット}-${アプリ名}-${レイヤー}-${環境} ビジネスユニット: Workspace を管理するビジネスユニットまたはチーム。 アプリ名: Workspace が管理するアプリケーションまたはサービスの名前。 レイヤー名: Workspace が管理するインフラストラクチャのレイヤー（例: ネットワーク、コンピューティング、ファイルストレージ）。 環境名: Workspace が管理する環境（例: プロダクション、ステージング、QA、開発）。アプリケーションチームにレイヤーがない場合は、組織全体での一貫性を保つために、その代わりに「main」または「app」を使用してください。 例：\nplatform-webapp-network-prod platform-webapp-compute-prod platform-webapp-filestore-prod platform-api-network-dev platform-api-compute-dev platform-api-database-dev 3. Volatility（変更頻度）によるグルーピング # Volatility とは、 Workspace 内のリソースの変化率を指します。データベース、VPC、サブネットなどのインフラストラクチャは、Web サーバーなどのインフラストラクチャに比べてはるかに頻繁に変化しません。長期にわたって存在するインフラストラクチャを不要な Volatility にさらすことで、意図しない変更のリスクが増加します。 Workspace の組織化を計画する際は、リソースを Volatility に基づいてグループ化してください。\n例：\nplatform-webapp-network-prod # 低頻度変更 platform-webapp-security-prod # 低頻度変更 platform-webapp-compute-prod # 高頻度変更 platform-webapp-filestore-prod # 低頻度変更 変更頻度の例：\n高頻度: コンピュートインスタンス（1日に数回スケール） 低頻度: データベースインスタンス（数ヶ月に1回程度） 4. Stateful / Stateless の分離 # ステートフルリソースは、データベースやオブジェクトストレージなど、データを永続的に保持するため削除して再作成できないリソースです。ステートフルリソースをステートレスリソースから独立して管理することで（例えばデータベースをコンピューティングインスタンスから分離するなど）、リソースの再作成を引き起こす操作の影響範囲を限定し、誤ったデータ損失から保護するのに役立ちます。 Volatility セクションの Workspace 構造を検討してください。ファイルストアとデータベースリソースはどちらもステートフルリソースであるため、これらを一緒に管理する可能性があります。一方、コンピューティングリソースはステートレスであるため、依然として別々の Workspace に配置する必要があります。\n# ✅ 良い例：Stateful と Stateless を分離 platform-webapp-network-prod # Stateful platform-webapp-filestore-prod # Stateful platform-webapp-compute-prod # Stateless # ❌ 悪い例：混在させる platform-webapp-all-prod # Stateful + Stateless が混在 5. 「権限」と「責任」による分離 # ベストプラクティスとして、チーム責任と必要な権限に基づいて Workspace を分割することが推奨されます。例えば、開発環境と本番環境を分離する必要があるアプリケーションの場合、それぞれに特別なネットワークとアプリケーションインフラストラクチャが要求されます。一つのアプローチとして、開発環境用に2つ、本番環境用に2つの合計4つの異なる Workspace を作成します。ネットワークチームのみがネットワーク Workspace へのアクセス権限を有します。\nこの構成では、ネットワークチームのみがネットワーク Workspace 内のリソースを管理するための権限を必要とし、他のユーザーはそれらの Workspace リソースを管理できません。 Workspace の範囲が広すぎる場合、ユーザーは Workspace 内の操作を行うために適切な範囲を超える権限を必要とする可能性があります。 チームごとに Workspace を分割することで、各 Workspace の責任範囲を限定し、チームが独自の管理領域を維持できるようになります。他の Workspace で管理されているリソースの属性を参照する必要がある場合、tfe_outputs データソースを使用して出力を共有できます。各 Workspace の範囲を限定し、必要な出力のみを他者と共有することで、 Workspace の状態から機密情報が漏洩するリスクを軽減できます。 Workspace の出力を共有するには、 Workspace の設定でリモート状態共有を明示的に有効にする必要があります。\n6. 大きな Terraform Plan/Apply を避ける # HCP Terraform および Terraform Enterprise は、エージェントを使用してワークロードを実行します。エージェントが Workspace の状態をリフレッシュするたびに、リソースの依存関係グラフを構築し、 Workspace 内の操作の順序を決定します。 Workspace が管理するリソースの数が増加するにつれ、これらのグラフはより大規模で複雑になります。グラフが拡大するにつれ、それらを構築するために必要なワーカーRAMも増加します。エージェントのパフォーマンスが低下したり、ワークロードの完了に時間がかかったりする場合は、 Workspace を分割して依存関係グラフのサイズを縮小する方法を検討することをおすすめします。\n7. Workspace の並行処理と Terraform の並列処理を比較する # 並行処理とは、HCP TerraformまたはTerraform Enterpriseが同時に実行できるプランと適用操作の数を指します。 HCP Terraformでは、エディションによって組織の最大並行処理数が制限されます。詳細については、HCP Terraformの料金プランをご確認ください。\nTerraform Enterpriseでは並行実行数を設定できますが、デフォルトでは10並行実行が設定されています。並行実行数を増やすと、Terraform Enterpriseのインストールに必要なメモリ量も増加します。詳細については、容量とパフォーマンスのドキュメントを参照してください。\n並列処理とは、Terraform CLIが単一のワークロード内で同時に実行するタスクの数です。デフォルトでは、Terraformは最大10の操作を並列実行します。terraform apply コマンドを実行する際、Terraform は状態ファイル内の各リソースをリフレッシュし、リモートオブジェクトと比較します。各リソースのリフレッシュ、作成、更新、または削除は個別の操作です。ワークロードが11つのリソースを作成する場合、Terraform は依存関係グラフ内の最初の10つのリソースを作成し、最初の10つのリソースの1つを作成し終えた後に11番目のリソースの作成を開始します。\nTerraformの並列処理を増加させることは可能ですが、これにより実行時のCPU使用率が上昇します。可能な場合は、大規模なTerraform構成をリソースの少ない小さな構成に分割することをおすすめします。長時間実行されるTerraformワークロードは、肥大化した Workspace スコープの早期の兆候です。\n運用時の継続的改善 🔄 # 最初からベストプラクティスに準拠できるのであれば最高なのですが、現実は様々な事情により準拠できないケースもあると思います。例えば、プロジェクトの期限、コスト、開発体制\u0026hellip;.上げだしたらキリがないです。ただし、そこで「ベストプラクティスを執らない」とはならないかと思います。個人的には「継続的にベストプラクティスに近づけること」が現場においては大事なのではないかと思います。初期構築段階、あるいはコミュニティ版 Terraform から HCP Terraform へ移行したばかりの段階では対応が難しい場合でも、日々の運用の中で継続的に改善していくことが重要なのです。\nまとめ 🎉 # かなり説得力のある観点が盛り込まれていたのではないでしょうか？ 最後に HashiCorp 公式のベストプラクティスに基づく Workspace 設計のポイントをまとめたいと思います。\n小さな影響範囲を保つ: 必要かつ論理的に関連するリソースのみをグループ化 公式推奨の命名規則: \u0026lt;business-unit\u0026gt;-\u0026lt;app-name\u0026gt;-\u0026lt;layer\u0026gt;-\u0026lt;env\u0026gt; の採用 Volatility （変更頻度）によるグルーピング: 変更頻度に基づくグルーピング Stateful / Stateless の分離: データ損失リスクの最小化 「権限」と「責任」による分離: チーム境界に沿った適切な権限管理 パフォーマンス重視: 大きすぎる Workspace は分割を検討、Terraform 実行時のパフォーマンスも考慮 これらの原則を実践することで、より安全で効率的な HCP Terraform 運用が実現できるのではないかと思います。\n次回は「HCP Terraform におけるブランチ戦略」について、今回の Workspace のベストプラクティスを前提とした内容で詳しく解説する予定です。お楽しみに！ 😊\nこの記事が参考になったら、是非 SNS でシェアしてください！ Hashicorp 公式ベストプラクティスに基づいた設計・運用で、皆さんのインフラ管理がより良くなることを願っています ✨\n","date":"2025年07月20日","externalUrl":null,"permalink":"/blogs/hcp-terraform-workspace-best-practice/","section":"Blogs","summary":"","title":"HCP Terraform Workspace 設計のベストプラクティス","type":"blogs"},{"content":" はじめに 👋 # こんにちは、ニンバスです！ 7月になり暑い夏がやってきましたね。皆さんいかが過ごしいでしょうか？くれぐれも熱中症にはお気をつけくださいね。 今回は最近私がよく触っている「HCP Terraform」の概要について触れていこうと思います。この記事で少しでも「HCP Terraform」について知っていただけると嬉しいです。それでは、Let`s Dive in! 🦄\nHCP Terraform とは？ # HCP Terraform の説明については Hashicorp 公式から解説されています。（以下、Google 翻訳）\nHCP Terraform は、チームが Terraform を共同で使用できるようにするアプリケーションです。一貫性と信頼性のある環境で Terraform の実行を管理し、共有状態データやシークレットデータへの容易なアクセス、インフラストラクチャへの変更を承認するためのアクセス制御、Terraform モジュールを共有するためのプライベートレジストリ、Terraform 構成の内容を管理するための詳細なポリシー制御など、様々な機能を備えています。\nWhat is HCP Terraform? これを私なりに解釈すると、「 HCP Terraform は Terraform の実行環境を提供する SaaS で、コミュニティ版 Terraform で実施していた State 管理や変数管理などの面倒くさいことを肩代わりしてくれるサービス 」です。\nHCP Terraform の大きな特徴 🚀 # HCP Terraformの大きな特徴は、GitHub や GitLab といった Version Control Service（以下、VCS）と連携し、 PlanからApplyまでをGUI上の操作で完結できるワークフローを提供しているところだと思います。\nコミュニティ版では、terraform コマンド(terraform plan や terraform apply など)を実行して、.tfファイルに記述したリソースを作成するかと思います。 このフローの直前には、VCS からリポジトリを clone したり、適切なブランチに切り替えたりといった作業があるかと思います。この作業は人間が実施することが多く、それを自動化するために GitHub Actions や AWS Codepipeline、Cloud Build などで独自のCI/CD パイプラインを構築・運用していたのではないかと思います。\nHCP Terraform では VCSと連携することができ、連携したリポジトリ上で PR あるいは MR が行われたことをトリガーし、HCP Terraform上で terraform planが自動的に実行されます。また、main(master)ブランチにマージされると、それをトリガーして自動的にterraform planが行われ、承認プロセスを挟んでterraform applyが実行されます。このようにVCS上のリポジトリを信頼できるリソースとして、自動的にプロビジョニングができるワークフローを HCP Terraform が提供しているのです。\nなぜ HCP Terraformを選ぶのか 🤔 # コミュニティ版でももちろんTerraformからリソースを作成することができます。ではなぜ、HCP Terraformを選ぶのでしょうか。それは、コミュニティ版にはない機能により、チーム開発や組織の生産性向上に寄与するとともに、ガバナンスを効かせることができるからです。\n機能紹介 # 全ての機能について紹介するとキリがないので、ここでは HCP Terraform ワークスペースの簡単な概要について触れたいと思います。\nワークスペース # コミュニティ版においてもワークスペースという概念が存在しますが、HCP Terraformのワークスペースはそれとは似て非なるものです。 Hashicorp公式ではこのように説明しています。（以下、Google 翻訳）\nワークスペースとは、Terraform によって管理されるインフラストラクチャリソースのグループです。\nHCP Terraform workspaces 少しわかりづらいかなと思いますので、図を用いて説明しようと思います。 例えば、以下のような Terraform プロジェクトがあったとします。\nterraform ├── README.md ├── terraform.tf ├── main.tf ├── outputs.tf ├── providers.tf ├── static-web-hosting.tf └── variables.tf HCP Terraform のワークスペースでは、このプロジェクトの Terraform コードを実行することになります。つまり、一つのプロジェクトを一つのワークスペースとしてグルーピングされていて、個別ワークスペースはTerraform実行に必要なものが含まれています。そして、個別ワークスペースは作業ディレクトリのように機能します。ワークスペース内ではTerraformを実行するためのVMがリモートで起動し、そのVM上で Terraformが実行されます。\n多くの場合、以下のようにリポジトリが論理的に分離されているかと思います。\n本番用 Terraform プロジェクト テスト用 Terraform プロジェクト 開発用 Terraform プロジェクト こういったケースに対して、ワークスペースもこのように作成することができます。\n本番用 Terraform プロジェクト === 本番用 ワークスペース テスト用 Terraform プロジェクト === テスト用 ワークスペース 開発用 Terraform プロジェクト === 開発用 ワークスペース 「 1 リポジトリ = 1 ワークスペース 」というところが理解できていれば OK です 👍🏻 変数（Variables） # また、ワークスペースにはいくつか重要な機能がありますが、その一つが「変数（Variables）」です。 コミュニティ版ではAWS、GoogleCloudといったクラウドプロバイダーに対して何かしらのリソースを作成する際に、認証情報（クレデンシャル）を変数(.tfvarsなど)または環境変数に設定すると思います。HCP Terraformにおいても同様に認証情報（クレデンシャル）を設定しなければなりませんが、リポジトリに認証情報を含めることなくワークスペース内で「変数（Variables）」を設定することができます。\n設定できる変数の種類は以下の通りです。\nTerraform variable \u0026hellip;. 主に.tfから参照する変数 Environment variable \u0026hellip;. Terraform が実行されるときに参照する環境変数 詳しくはHashicorp公式ドキュメントを参照すると良いでしょう。\nHCP Terraform Workspace variables 各種プロバイダーの認証情報の設定方法はここでは詳しく触れませんが、Hashicorp公式からは動的クレデンシャル（Dynamic provider credentials）を利用することを推奨されています。\nUse dynamic credentials with the provider in HCP Terraform State管理 # もともとコミュニティ版 Terraform を触ったことがある方なら理解しやすいと思いますが、Terraform を実行すると同時に リソースの状態を記録する state ファイルが作成されます。この state ファイルは実行端末もしくはAmazon S3やGoogle Cloud Storageなどに保管されることが多いかと思います。しかし、HCP Terraformではこのstate ファイルをHCP Terraform上のワークスペースの中で暗号化し保管してくれます。\nポリシー # Terraformの活用が進んでいるところであれば、Terraformのコード規約が作成されているのではないかと思います。また、AWS や Google Cloud といったクラウドプロバイダーの利用ガイドラインを組織の中で定めていたりすることもあると思います。そういった定められたルールを逸脱した Terraform コードがあった場合にどのようにルールを遵守させるのが良いでしょう。これまでは、厳格にコードレビューをしていたはずですが、あくまでもレビューするのは人間なのでどうしても全てを完璧にレビューすることは難しいです。\nHCP Terraformでは「ポリシー」という機能を提供しています。Hashicorp 公式ドキュメントでは次のように説明しています。\nこのトピックでは、HCP Terraform のポリシーの概要について説明します。ポリシーとは、Terraform 実行のルールであり、Terraform プランがセキュリティルールとベストプラクティスに準拠していることを検証できます。\nHCP Terraform policy enforcement overview これだけだとわかりづらいので、少し補足します。コード規約やガイドラインなどで定めたルールをポリシーに落とし込むことができ、このポリシーはHCP Terraform上のワークスペースに適用することができます。ポリシーが適用されたワークスペース内でPlan/Applyが実行されたときに、HCP Terraformはその内容とポリシーを突き合わせます。ここで違反があった場合には、Plan / Applyを止めることができます。一言で言うと「ルールに違反しているコードは、実行させない」ということができるのです。\nこのポリシーを作成する際には、ポリシー言語である「Sentinel」もしくは「OPA」がサポートされています。 どちらの言語にもポリシーの適用レベルを設定することができます。\nSentinel であれば、適用レベルは以下の3つを設定することができます。\nAdvisory \u0026hellip; 推奨レベル Soft Mandatory \u0026hellip; 必須だが承認があればその限りではない Hard Mandatory \u0026hellip; 例外なく必須 OPA であれば、適用レベルは以下の2つを設定することができます。\nAdvisory \u0026hellip; 推奨レベル Mandatory \u0026hellip; 例外なく必須 （私は柔軟に適用レベルを設定したかったのでSentinelを利用しています）\nこのポリシーを活用することで、Policy as Codeを実践することができ、組織やチームに対してガバナンスを効かせることができます。 私が現在いる組織では、「Terraformコード規約」や「クラウドコスト最適化ガイドライン」をポリシーに落とし込んで、ガバナンス強化とコスト最適化を実践しようとしています。（この話は、機会があればどこかで詳しく書きたいです😀）\nPolicy enforcement levels 料金体系 # HCP Terraformにはいくつか料金プランが用意されています。\n無料プラン # Hashicorp 公式ドキュメントでは次のように説明されています。\n小規模なチームでは、リモート Terraform 実行、VCS 統合、プライベート モジュール レジストリ、シングル サインオン、ポリシー適用、タスク実行など、HCP Terraform のほとんどの機能を無料で使用できます。無料組織では、管理対象リソースは500個までに制限されています。詳細については、「管理対象リソースとは」をご覧ください。\nPlans and Features - Free Organizations 個人開発で、手軽にTerraform実行環境を用意したい場合には無料プランで十分だと思います👍🏻\n有料プラン # 無料プランでは開放されていない機能を利用したい場合は有料プランを検討してください。Hashicorpでは次のプランが用意されています。\nStandard Plus Premium Enterprise 各プランの比較については Hashicorp 公式ページに掲載されているので、下のリンクから参照ください。\nHashiCorp Product Pricing 私の知人によれば企業レベルになると、Plus以上を契約することが多いようです👀\nまとめ 💡 # いかがでしたでしょうか？まだまだ紹介したい機能がたくさんありますが、少しでも HCP Terraformについて知ってもらえたのであれば嬉しいです。今後も HCP Terraformについて発信していきたいと思いますので、続報をお待ちいただければと思います。それでは、また次回お会いしましょう！See ya 👋🏻\n","date":"2025年07月12日","externalUrl":null,"permalink":"/blogs/what-is-hcp-terraform/","section":"Blogs","summary":"","title":"HCP Terraform とは？","type":"blogs"},{"content":" はじめに 👋 # こんにちは、Nimbus です。\n先日、HashiCorp Certified: Terraform Associate（003）を受験し、無事に合格することができました。\nTerraformは業務で長く使っていたこともあり、受験前は「今さら勉強しなくてもなんとかなるだろう」と思っていました。\nしかし、実際に準備を進めていく中で、実務ではあまり意識していなかった知識の不足に何度も気づかされました。\nこの記事では、試験を受けた理由や勉強方法、受験当日の流れ、そして感じたことなどをまとめています。\nこれから受験を考えている方の参考になれば幸いです。\nなぜ資格を取ろうと思ったのか？ 🎯 # Terraformはこれまで5年ほど業務で使用しており、AWSやGoogle Cloud、GitHub、TFEなど、複数のプロバイダーを組み合わせてIaC環境を構築してきました。\nまた、HCP TerraformのPrivate Module Registryを利用して社内向けのモジュールを管理しているため、自分の中ではある程度使いこなしているつもりでした。\nそんな中で、「スキルを一度客観的に証明しておこう」と思ったのが受験のきっかけです。\nちょうど社内にTerraform Associateの資格保有者がいなかったことも後押しになりました。\n試験対策と学習方法 📘 # 実務経験だけでは足りなかったこと # Terraformを使っているからといって、試験もそのまま通用するとは限らないことを痛感しました。\n以下のような内容は、普段の業務では意識する機会が少なく、試験勉強で改めて学び直しました：\nterraform plan -refresh=false などの細かなCLIオプション S3以外のバックエンド構成の違い Public Registryの仕様とベストプラクティス CLIベースのworkspace操作 あまり使わないプロバイダーの認証設定 など 「普段やっていること」と「問われること」の間にあるギャップを埋めるのが、試験対策のポイントだと感じました。\n使用した教材 🛠 # 私が活用した教材は以下の通りです：\nTerraform 公式ドキュメント（RegistryやLearnが特に役立ちました） Udemyの試験対策講座（Terraform Associate 2025対応） HashiCorp Certified: Terraform Associate 2025 UdemyのPractice Exam（模擬試験） HashiCorp Certified: Terraform Associate Practice Exam 2025 GitHubのハンズオンリポジトリ 特に模擬試験の方は、本番とよく似た出題形式になっており、時間配分や英語の設問への慣れにとても効果的でした。\n英語への備え 🗣️ # Terraform Associateの試験はすべて英語で行われ、翻訳機能もありません。\nTerraformのドキュメントは英語で読む機会が多かったとはいえ、試験形式になると難しさを感じました。\nそのため、英語の対策として、以下を実践しました：\n模擬試験は英語のまま解く 普段の業務でもドキュメントは英語で読むよう意識 Duolingoで毎日10分程度、英語学習を継続 Duolingoの効果がどこまであったかは分かりませんが、「英語にも取り組んだ」という安心感は得られたと思います。\n試験の準備と申し込み ✍️ # Terraform Associateはオンラインで受験できますが、環境準備にはいくつか注意点があります。\n必要なもの ✅ # パスポートなどの顔写真付きの政府発行ID（試験官が外国人のため） 静かで誰も入らない個室（受験中の立ち入りは不可） 安定したインターネット接続 Webカメラとマイク 片付いた机の上（飲み物は透明容器のみ可） 当初は外部の個室ブースを検討しましたが、スマートフォン操作が必要なため「スマホ持ち込み禁止」のルールと矛盾して断念。\n結果的に、自宅の寝室を片付けて受験場所としました。\n試験当日の流れ 📅 # チェックイン〜試験開始 # 試験時間の15分前になると、ポータルにログインして以下の確認が行われます：\nシステムチェック（カメラやマイクの動作確認） 監督官との英語チャット（自動翻訳あり） 身分証の提示と部屋の360度撮影 机の上下の確認、不要なタブやアプリの終了 指示は明確で、チャットで「OK」と返すだけなので特に問題はありませんでした。\n試験本番 ⏱️ # 時間：60分 問題数：57問 形式：単一選択・複数選択式 問題内容は非公開ですが、Terraformのドキュメントを英語で読めていれば理解は可能なレベルでした。\nTOEICで言えば600点前後の読解力があれば十分だと思います。\nなお、試験中は一切声を出してはいけません。\n私は普段、問題をつぶやきながら考える癖があるので、うっかり話しそうになって焦りました。\n結果とその後 🎉 # 試験が終了すると、アンケート画面のあとにすぐ合否が表示されます。\n私の場合、「Pass」の文字が表示されて、ようやく肩の力が抜けました。\n合格後にできること：\n試験履歴・領収書のダウンロード（ポータル上から） 48時間以内に公式の合否通知メールが届く Credlyバッジを発行して、LinkedInなどに掲載可能 スコアの詳細などは表示されませんが、結果が「合格」であれば、それで十分だと感じました。 後日、Credlyからバッジを受け取り、ようやく合格したことを実感できました。\nまとめと、これから受ける方へ 💡 # Terraform Associateは、実務経験があっても油断できない試験でした。\nむしろ業務で使っているからこそ、普段触れていない部分を試験で気づく、ということが多かったです。\n試験勉強を通じて、自分の知識の整理や補完ができたことが、結果以上に大きな収穫でした。\n勉強のポイント： # ✅ 実務経験だけでなく、網羅的な知識が求められる ✅ 公式ドキュメントは信頼できる学習リソース ✅ 模擬試験で形式や出題傾向に慣れておく ✅ 英語の設問に対応できるよう、最低限のリーディング力をつける ✅ ハンズオンで実際に触れることが理解を深める おわりに ✨ # Terraform Associateの受験は、Terraformに対する理解を改めて見直す良いきっかけになりました。\nこれから受験を検討している方にも、きっと多くの学びがあるはずです。\n少しでも参考になればうれしいです。受験、頑張ってください！\n","date":"2025年06月29日","externalUrl":null,"permalink":"/blogs/passed-terraform-associate-exam/","section":"Blogs","summary":"","title":"Terraform Associate に合格しました！","type":"blogs"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"皆さん始めまして！ブログを書き始めました、ニンバスと言います。\n経歴 # クラウドインフラエンジニアとして4年以上の実務経験があります。主にAWSを活用したシステム設計、構築、移行、運用に携わってきました。\n得意分野 # AWSを使ったインフラ設計・構築 特にVPC、EC2、RDS、S3、CloudFront、ECSなどのコアサービスを活用 Terraformを用いたインフラのコード化 Infrastructure as Code（IaC）の実践経験が豊富 オンプレミスからAWSへの移行経験多数 保有資格 # クラウド # AWS Certified Solutions Architect - Associate AWS Certified Developer - Associate Google Professional Cloud Architect IT基盤 # 基本情報技術者試験 ITパスポート ITIL V4 Foundation 趣味 # 技術情報のキャッチアップ 毎週AWSのアップデート情報をチェック AWS Summit TokyoやAWS re:Inventの参加・情報収集 映画鑑賞 最近はMarvel、Disney、DC マンガ ワンピース、キングダム、推しの子、アオアシ、ブルーロック、怪獣８号など スポーツ バドミントン 日本代表とLaLigaのサッカー観戦 これから # このブログでは、AWS・Terraformを中心に、実践的な技術情報を発信していきます。\nAWSサービスのハンズオン\n新しいサービスや機能を実際に試してみた記録 ユースケースに基づいた構築手順の解説 つまずきポイントと解決方法の共有 Terraformの実践テクニック\nモジュール化のベストプラクティス 実際のプロジェクトで使える設計パターン リファクタリングのテクニック 技術情報のキャッチアップ\nAWS最新アップデートの検証結果 気になる新機能を実際に試してみた感想 re:InventやSummitなどのイベントレポート インフラエンジニアの視点で、実際に手を動かして検証した内容を中心に投稿していきます。「やってみた」「試してみた」といった実践的な内容を通じて、皆さんのお役に立てる情報を発信していければと思います。\nどうぞよろしくお願いします！😃\n","externalUrl":null,"permalink":"/about/","section":"Nimbus の技術ブログへようこそ!","summary":"","title":"ブログ始めました、ニンバスです","type":"page"}]