Terraform×Boundary×Vaultで構築する「ID中心」のゼロトラスト・データプレーン
境界型防御の時代は終わった。VPNを接続し、IPアドレスでアクセス制御を行うという旧時代の遺物は、クラウドネイティブな環境において「脆弱性の温床」でしかない。
真のゼロトラストとは、「誰が」「何を」「どのタイミングで」アクセスするかの認可を、ネットワーク境界ではなくIDとセッションに委ねることだ。本稿では、HashiCorpエコシステム（Terraform, Vault, Boundary）を完全にコード化し、アクセス権を動的に生成・廃棄する「生きたインフラ」の構築論を説く。
—
1. アーキテクチャの真髄：動的信頼の連鎖
このアーキテクチャの心臓部は、「Terraformによる環境プロビジョニング」と「VaultによるJust-in-Time(JIT)クレデンシャル」、そして「Boundaryによるセッション・プロキシ」の三位一体にある。
- Terraform: インフラの定義と、Boundary/Vaultのコンフィグの宣言的構築。
- Vault: データベースやクラウドの永続的な認証情報を排除し、数分で失効する動的シークレットを払い出す。
- Boundary: ネットワークルーティングの意識を排除し、IDベースでターゲットへのコネクションをトンネリングする。
構築すべきフロー
1. TerraformがVaultの動的シークレットエンジンとBoundaryのTarget/Hostをプロビジョニング。
2. エンジニアはBoundaryクライアントを介して認証。
3. BoundaryはVaultから取得した一時的なクレデンシャルを使用してターゲットへ接続を中継。
4. セッション終了後、クレデンシャルは即座に無効化される。
—
2. Terraformによる「動的シークレット」と「境界」のコード化
単にリソースを並べるのではない。Vaultの`database`シークレットエンジンとBoundaryの`target`をTerraformの依存関係グラフ（DAG）に組み込むことで、インフラ構築と同時にアクセス権が担保される状態を作る。
Vault側: 動的ユーザー生成エンジニアリング
resource “vault_database_secret_backend_role” “db_admin_role” {
backend = vault_mount.db.path
name = “app-admin-role”
db_name = vault_database_secret_backend_connection.postgres.name
creation_statements = [“CREATE ROLE \”{{name}}\” WITH LOGIN PASSWORD ‘{{password}}’ VALID UNTIL ‘{{expiration}}’; …”]
default_ttl = 300 # 5分で強制失効
}
Boundary側: IDベースのターゲット定義
resource “boundary_target” “db_target” {
type = “tcp”
name = “production-db”
scope_id = boundary_scope.project.id
default_port = 5432
# Vaultの動的クレデンシャルを注入するプラグイン構成
brokered_credential_source_ids = [boundary_credential_library_vault.db_creds.id]
}
極限のハック: ここで重要なのは、`default_ttl`を極限まで絞り込むことだ。万が一セッションがハイジャックされても、攻撃者が利用できる時間は数分に制限される。これは「セキュリティの劣化」ではなく「運用コストの最小化」である。
—
3. パフォーマンスとスケーラビリティの最適化ハック
Boundary Workerの配置とメモリ管理
BoundaryのWorkerは、トラフィックが集中するボトルネックになり得る。
- Workerの分散配置: ターゲットの近くにWorkerを配置せよ。トラフィックは暗号化されたBoundaryプロトコルでカプセル化されるため、パブリックインターネットを経由してもセキュアだが、レイテンシを考慮しVPC内部にWorkerをオートスケールさせる構成（AWS ASG等）が必須だ。
- メモリ消費の抑制: 多数のセッションを捌く場合、Workerのメモリ監視を厳密に行う。`GOGC`環境変数を調整し、GCの頻度を最適化することで、高負荷時のスパイクを抑えることができる。
独自自動化スクリプトによるバリデーション
Terraformの実行後に「アクセス可能か」をテストするスクリプトをCI/CDパイプラインに組み込む。
構築後の生存確認：Boundary APIを叩いてエンドポイントの健全性を検証
boundary targets read -id $TARGET_ID -format json | jq ‘.item.attributes.name’
if [ $? -ne 0 ]; then
echo “Critical: Boundary target mapping failed.”
exit 1
fi
—
4. 伝説的エンジニアからの提言
多くの現場が陥る罠は、「自動化を目的化すること」だ。
TerraformでBoundaryやVaultを構築するのは、あくまで手段に過ぎない。真の目的は、開発者が「アクセス権の設定」という面倒な手続きを脳内から排除し、「認証・認可が自動的に最適化されている状態」でコーディングに集中できる環境を物理的に強制することにある。
- 冪等性の担保: `terraform plan`で差分が出ないことは当然。Vaultのシークレットエンジンの設定変更が、既存のBoundaryセッションにどう影響するかまで設計図（図面）に落とし込めているか？
- 完全自動化の果て: 人間がVaultのUIにログインして設定を行うのは「敗北」だ。すべてのポリシーはGitで管理され、Terraformが適用した瞬間、ネットワークの壁がIDの壁へと塗り替えられる。これこそが、SREが追求すべき「インフラのコード化」の到達点だ。
この構成を導入する君たちは、もはや「ネットワークを守る番人」ではない。「アクセスフローを設計するアーキテクト」だ。誇りを持って、この動的な基盤を構築してほしい。
—
本稿で用いたコードは、Terraform 1.5+ および Vault/Boundary の最新GA版を前提としている。APIの仕様変更には常に追従せよ。それがプロフェッショナルの責務だ。