HCP Terraformの概要と主な機能説明

HCP Terraformについて色々と調査・検証したので、忘備録を兼ねて記事にしました。

HCP Terraform(Terraform Cloud)について、概要・主な機能説明・想定される使用感について紹介します。なお、これを扱うにはTerraform・GitHubについてある程度理解している必要があります。
また、今回はFreeプランを使うことを前提としております。そのため、チーム作成やユーザーごとの権限付与などの一部機能については説明しません。

概要

HCP Terraformとは

HCP Terraform(HashiCorp Cloud Platform Terraform)は、HashiCorp社が提供するTerraformのマネージドサービスです。以前は「Terraform Cloud」という名称でしたが、2024年にHCP Terraformへと名称変更されました。

このサービスは、Terraformをクラウド上で実行・管理するためのプラットフォームを提供します。ローカル環境でTerraformを実行する代わりに、クラウド上の安全な環境でインフラストラクチャのプロビジョニングと管理を行うことができます。

主な特徴として、以下が挙げられます：

• リモートステート管理: Terraformのステートファイルを安全に保管し、チーム間での共有を可能にします
• リモート実行環境: Terraform実行環境をクラウド上で提供し、一貫した実行環境を保証します
• VCS連携: GitHub、GitLabなどのバージョン管理システムと統合し、コードの変更を自動的に検知・実行できます
• Policy as Code: Sentinel/OPAを使用したポリシー管理により、インフラのガバナンスを強化できます

HCP Terraformを使うメリット

HCP Terraformを導入することで、以下のようなメリットが得られます：

1. ステート管理の安全性向上

• ステートファイルが自動でクラウド上に保存される

2. 実行環境の統一

• Terraformのバージョンやプロバイダーのバージョンを一元管理
• チームメンバー全員が同じ環境で実行できる
• ローカル環境の差異による問題を排除

3. VCS連携による自動化

• コードのプッシュを検知して自動的にPlan/Applyを実行
• プルリクエストにPlan結果を自動コメント
• レビューフローとの統合が容易

4. セキュリティの強化

• 変数を暗号化して安全に管理
• クラウドの認証情報をローカルに保存する必要がない
• 実行ログの一元管理と監査が可能

5. ガバナンスの実現

• Policy as Code(Sentinel/OPA)による自動チェック
• 組織のポリシーに違反する変更を自動的に検知・ブロック
• コンプライアンス要件への対応が容易

GitHub Actionsを使う場合との比較

GitHub ActionsでもTerraformの実行を自動化できます。
ですが、GitHub Actionsは利用者が自由にワークロードをカスタマイズできます。また、terraform applyの実行には、クラウドに対して管理者権限相当の強い権限が必要となります。
そのため、GitHub ActionsのみでTerraformを実行する場合、GitHub Actionsを悪用して環境に対しaws-cli等を用いた不正な操作が可能になってしまいます。
一方で、HCP Terraform はTerraformの実行しかしないため、強い権限を与えても不正な操作が行われるリスクが小さいです。
このように、GitHub ActionsではなくHCP Terraformを使う利点はあります。
他にも、HCP Terraformには以下の優位性があります：

HCP Terraformの優位点:

• ステート管理が標準で提供され、追加設定が不要
• Terraform専用のUIで実行履歴やステート差分が見やすい
• Policy as Codeの機能が標準搭載
• Terraformの実行環境をHashiCorpが管理・最適化

一方で、GitHub Actionsには以下の優位性があります。

GitHub Actionsの優位点:

• ワークフローのカスタマイズ性が高く、柔軟な構成が可能
• Terraform以外のツール(linter、セキュリティスキャン、テストなど)との統合が容易

そのため、以下のようにHCP TerraformとGitHub Actionsを組み合わせることで、より効率的かつ安全な開発が可能となります。

組み合わせパターン: コード品質チェックとTerraform実行の分離

• GitHub Actions側の役割:
  • terraform fmtによるコードフォーマットチェック
  • terraform validateによる構文検証
  • tflint、tfsecなどのlinterやセキュリティスキャンツールの実行
  • ユニットテストやインテグレーションテストの実行
• HCP Terraform側の役割:
  • terraform planの実行とPlan結果の可視化
  • terraform applyの実行と変更の適用
  • ステート管理と実行履歴の保持

この分離により、GitHub Actionsで迅速にコード品質をチェックし、同時にHCP TerraformでPlanを実行できます。結果として、Terraformの実行結果とコードの品質を並行して確認でき、開発サイクルを短縮できます。

このように、両者の強みを活かした使い分けにより、開発の効率性とインフラの安全性を両立できます。

HCP Terraformを使う際の注意点

HCP Terraformを導入・運用する際には、以下の点に注意が必要です：

1. 機微なセキュリティ要件に対応しづらい

• セキュリティポリシー的にクラウド外部にステートファイルや設定情報を保存できない場合、利用が難しい
• コンプライアンス要件によっては、HCP Terraform自体にアクセスできず、利用が承認されないケースがある

2. terraformコマンドの実行時間の制約

• ローカル実行に比べて若干のオーバーヘッドがある
• ネットワーク遅延の影響を受ける可能性

3. ステート管理の依存

• HCP Terraformのサービス停止時にはステートにアクセスできない
• ステートのバックアップ戦略を検討しておく

4. セキュリティ設定の重要性

• 変数に含まれる機密情報の適切な管理が必須
• VCS連携時のアクセス権限の設定ミスに注意

主な機能説明

Organizations

この機能の役割

HCP Terraformの各種機能を全体管理する。HCP Terraformにおける最大単位です。複数のプロジェクトやWorkspacesをまとめ、ポリシーやユーザー管理を一元化します。

Users

組織に所属するユーザーの管理機能です。ユーザーの招待、削除、権限設定(有料プランのみ)などを行います。Freeプランでは全員が同じOwner権限となり、組織内のメンバー管理が可能です。

Settings (Policies)

ポリシー定義を設定するものです。ここでは、コードや実行内容がルールに準拠しているかを自動チェック・制御します。ポリシーはSentinelまたはOpen Policy Agent(OPA)で記述していきます。
また、ポリシー違反が発生した際にどのような対応を行うかを以下の3種類から選ぶことができます。

• Advisory
  ポリシー違反検知時に警告を表示します
• Soft mandatory
  ポリシー違反検知時に警告を表示しコードの実行を停止しますが、管理者などが強制的に実行させることができます(このポリシー設定はFreeプランでは1つのOrganizations内で1つしか設定できません)
• Hard mandatory
  ポリシー違反検知時に警告を表示しコードの実行を停止します(このポリシー設定はFreeプランでは1つのOrganizations内で1つしか設定できません)

このポリシーを実際に適用させるには、後述するPolicy setsで割り当てる必要があります。
ここで、このポリシーは複数設定できますが、Freeプランでは5つが上限であることに注意してください。

Settings (Policy sets)

先に説明したポリシーをセットとして管理します。ここでは主に、ポリシーをどのProjectsやWorkspacesに適用するかを設定します。
ここで、Policy setsはFreeプランでは1つしか作成できないことに注意してください。

Projects

この機能の役割

関連するWorkspacesをグループ化し、リソースや設定の管理を効率化します。プロジェクト単位で権限や変数セットを適用できます。

Settings (Variable sets)

プロジェクト内の複数Workspacesに共通で使う変数セットを定義します。ここでもOrganizationsの場合同様にポリシーをどのWorkspacesに適用するかを設定できます。

変数はTerraformコードで使うtfvarsに相当する"Terraform variable"と、Terraformを実行するマシンが使う環境変数に相当する"Environment variable"を設定できます。また、設定項目に"HCL"と"Sensitive"があります。それぞれの説明は以下の通りです。

• HCL
  ここで設定した文字をHashiCorp Configuration Language(HCL)として解釈します。["ap-northeast-1", "us-east-1", "eu-west-1"]のようなリストやtrueなどのbooleanを文字列ではない形で渡したいときに使用します。
• Sensitive
  ここで設定した文字は、HCP TerraformのUI画面から表示されなくなり、Owner権限を持つユーザーからであっても確認できなくなります。そのため、AWS_ACCESS_KEY_IDのような機密性の高い変数を入れるときに使用します。

Workspaces

この機能の役割

HCP Terraformで管理するTerraformコードを実際に実行する単位です。環境ごと(dev/stg/prd等)や用途ごとに分けて管理し、tfstateや実行履歴を保持します。基本的に、開発者はWorkspaces内の項目を触ることになります。

Runs

Terraformのplan/applyなどの実行履歴を見ることができます。
また、HCP Terraformではプルリクエストやマージをトリガーとしてplan/applyを実行しますが、この項目にある"New run"を使うことで任意のタイミングでplan/applyを実行できます。ここで、詳細は後述しますが、plan/applyを実行するブランチ及びディレクトリは"Settings"以下の"VCS branch"及び"Terraform Working Directory"に記述した所であることに注意してください。さらに、"Current Run"または"Run List"のRun履歴を押下することで、各Runの詳細(差分、ログ、実行者など)を確認できます。

Variables

Workspacesごとに管理する変数です。設定する項目は先ほど説明したProjectsのVariablesと同じです。ただ、ProjectsとWorkspaces両方で同じ変数を定義した場合、Workspacesでの設定が優先されます。

Settings (General)

Workspacesの基本設定を行います。名前、説明、Terraformバージョンなどを管理します。それ以外にも、以下の設定が行えます。

• Auto-apply
  通常applyの実行は、先ほどの"Runs"でplanが実行された後に人の手で承認ボタンを押下する必要があります。この承認を行わず、planに成功したら自動でapplyも行うようになります。チェック項目は2つあり、それぞれの内容は以下の通りです。
  • Auto-apply API, UI, & VCS runs
    マージや特定ブランチへのpushなど、apply実行トリガーとなり得る操作を行った場合に自動でapplyを実行します。
  • Auto-apply run triggers
    特定の別Workspacesでapplyが完了した時、このWorkspacesでもplanを実行するように設定できます。このタイミングで、自動でapplyします。
• Terraform Working Directory
  Terraformを実行するディレクトリを記述します。/devのように、Workspacesの用途にあったディレクトリを設定することで、リポジトリで管理している他の環境に影響を与えないようにできます。なお、デフォルトではリポジトリのルートディレクトリとなっています。
• Remote state sharing
  このWorkspacesでoutputより公開したterraform_remote_stateを受け取れる範囲を設定できます。公開単位は以下の3つです。
  • このWorkspacesが所属しているOrganizations内全て
  • このWorkspacesが所属しているProjects内全て
  • このWorkspacesが所属しているProjects内の特定のWorkspaces

Settings (Version Control)

GitHub等のVCS連携設定をします。リポジトリの指定やブランチ、トリガー条件を設定し、コード変更を自動検知・実行します。具体的な設定項目は以下の通りです。

• Terraform Working Directory
  リポジトリ内でTerraformを実行するディレクトリを指定します。"Settings (General)"で設定したものと同じで、リンクしています。
• Auto-apply
  planに成功したら自動でapplyも行うようになります。Settings (General)で設定したものと同じで、リンクしています。
• VCS Trigger Type
  "Runs"でplan/applyが実行されるVCSへの操作を記載します。設定内容は以下の通りです。
  • Branch-based
    特定のブランチに対し、pushなどで変更を加えた場合にplan/applyが実行されます。これを選択した際に"VCS branch"という項目が表示され、ここでブランチを指定できます。なお、デフォルトはmainブランチです。
  • Tag-based
    特定のフォーマットが付いたタグが付いた場合にplan/applyが実行されます。これを選択した際に"Semantic Versioning"という項目が表示され、タグフォーマットを設定できます。
• Automatic Run Triggering
  plan/applyを自動実行するリポジトリの変更箇所を設定します。設定内容は以下の通りです。
  • Always trigger runs
    全ての変更に対してplan/applyを実行します。
  • Only trigger runs when files in specified paths change
    特定のファイルやパスに対して変更があった場合にplan/applyを実行します。ここで、/dev/**/*や/modules/**/*のように設定することで、ある環境へ変更した際に他の環境ディレクトリでもplan/applyを実行することを防げます。
• Automatic Run Triggering
  ここの"Automatic speculative plans"にチェックを入れることで、プルリクエスト実行時およびその後のpush時にplanを自動実行します。この時はplanしか実行されず、applyの実行トリガーとはなりません。
  ここで、planの実行場所は先の"Only trigger runs when files in specified paths change"で制御できます。しかし、リポジトリへの全てのプルリクエストがトリガーとなることに注意してください。例として、"Only trigger runs when files in specified paths change"で/dev以下のパスを設定したとしても、同リポジトリの/prdに対してのプルリクエストに反応して/devにplanを実行してしまいます。
  また、先の"VCS Trigger Type"でブランチやタグを設定した場合は、この"Automatic Run Triggering"がOFFになるような挙動をします。