Terraform Cloud AgentをK8sで飼い慣らせ：ハイブリッドクラウドの「最後の聖域」を突破する技術
「パブリックなTerraform Cloudで管理したいが、リソースは強固なファイアウォールの内側にある」
このジレンマに直面したとき、多くのエンジニアは「VPNを繋ぐ」「踏み台経由のプロキシを書く」といった、運用負荷とセキュリティリスクが同居する茨の道を選びがちだ。だが、答えはシンプルだ。Terraform Cloud AgentをオンプレミスのKubernetesクラスター内に「潜伏」させればいい。
今回は、HashiCorpの公式エージェントをK8s上でセキュアかつ堅牢に稼働させ、ハイブリッドクラウドIaCの「真の自動化」を実現する知見を共有する。
—
1. なぜ「Agent」が必要なのか？その本質
Terraform Cloudのマネージド実行環境は、パブリックIPを持つリソースには最強だが、VPC内のプライベートエンドポイント（RDS, Internal LB, On-prem DB）には届かない。
AgentをK8s内にデプロイすることで、「外側からコネクションを受け入れる」のではなく「内側からOutboundで制御プレーンに接続する」という、極めてセキュアなネットワークアーキテクチャが完成する。
2. Helmによるデプロイ：実戦的なYAML構成
公式のHelmチャートを使うのは基本だが、プロダクションで使うなら「リソース制限」と「シークレット管理」を極めなければならない。
values.yaml (Production Ready)
replicaCount: 2 # 冗長性のため最低2。オートスケーリングを考慮するならHPAを別途設定
image:
repository: hashicorp/tfc-agent
tag: latest
認証情報は必ずK8s Secret経由で注入すること
token: “YOUR_TFC_AGENT_TOKEN”
リソース制限は必須。テラフォームの実行はメモリを食うため余裕を持つこと
resources:
limits:
cpu: “500m”
memory: “512Mi”
requests:
cpu: “200m”
memory: “256Mi”
ネットワークの隔離：Agent専用のNamespaceを切り、NetworkPolicyで制御せよ
networkPolicy:
enabled: true
allowEgress:
- to:
- ipBlock: { cidr: 0.0.0.0/0 } # Terraform Cloud APIへの通信許可
3. プロの現場で差がつく「隠れたテクニック」
① VS Codeの「神プラグイン」と設定
IaCの生産性を劇的に上げるには、エディタの力は不可欠だ。
- HashiCorp Terraform (公式): 言うまでもない。`terraform.languageServer.enable` は `true` 一択。
- TFLint: これを入れずにコードをコミットするのは、「テストなしで本番デプロイする」のと同じ。`tflint-ruleset-aws` 等のプラグインと組み合わせ、CIで強制実行させよ。
- Indent-rainbow: 複雑なHCLのネストを視覚的に理解するのに役立つ。
② 「絶対やるべき」設定の共有化ルール
チームの生産性を下げないための鉄則は、「手元のCLIバージョンとAgentの実行環境を一致させる」ことだ。
- `.terraform-version` ファイルを必ずルートに置き、`tfenv` を使用して全員が同じバージョンを使うよう強制する。
- `terraform fmt` はプリコミットフックに組み込む。コードの美学は議論するものではなく、自動化すべきものだ。
③ 高速化のための裏技「キーボードショートカット」
`terraform plan` や `apply` を打つために指をホームポジションから外すのはナンセンスだ。
VS Codeの `keybindings.json` に以下を仕込め。
{
“key”: “ctrl+alt+p”,
“command”: “workbench.action.terminal.sendSequence”,
“args”: { “text”: “terraform plan\n” }
}
これで、コーディングの勢いを殺さずに即座にプランを確認できる。
—
4. セキュリティ担保の深淵
AgentをK8sに置くということは、そのPodが社内NWへの「鍵」を持つことを意味する。以下の3点を守れ。
1. IAM Role for Service Accounts (IRSA): クラウド上のリソースを操作する場合、ノードのIAM権限を使わず、Podに最小権限のIAMロールを付与せよ。
2. Ephemeral Storage: Agentの作業ディレクトリは `/tmp` ではなく、Podのライフサイクルに紐づく `emptyDir` を使い、実行後に確実にゴミが消えるようにする。
3. Audit Logging: Agentのログは即座にFluentd/Loki等で外部ストレージに転送せよ。誰が・いつ・どのリソースを変更したか、エージェント側のログからも追跡できるようにしておくことが、障害調査の「最後の一手」となる。
結論
Terraform Cloud Agentをオンプレミスに構築することは、単なるネットワークのブリッジではない。それは、「クラウドの柔軟なガバナンス」を「オンプレミスの堅牢な環境」へと拡張する行為だ。
この構成を一度構築してしまえば、開発者はインフラの場所を意識することなく、プルリクベースでセキュアなインフラ変更が可能になる。これこそが、現代のSREが目指すべき「隠れたインフラの民主化」だ。
さあ、今すぐYAMLを書き、クラスターにデプロイし、IaCの次のステージへ進もう。