こんにちは！インフラ構成管理の世界へようこそ。日々の運用、本当にお疲れ様です。
システムの自動化を進める中で、誰もが一度は頭を悩ませるのが「機密情報（シークレット）の扱い」ですよね。データベースのパスワード、APIキー、SSL/TLSの秘密鍵……これらをどうやって安全に、かつ全自動でターゲットサーバーに配置するか。
「HieraのデータをGitHubにコミットしたいけれど、暗号化（hiera-eyamlなど）の鍵管理が面倒くさい……」
「カタログ（Puppet Serverが生成する構成指示書）にプレーンテキストのパスワードが残ってしまうのが不安……」
そんな悩みを一撃で解決し、インフラセキュリティを極限まで高めてくれるのが、構成管理ツール「Puppet」と機密情報管理のデファクトスタンダードである「HashiCorp Vault」の統合です。
この記事では、単に「Vaultからデータを引っ張ってくる」だけの一歩進んだ方法ではなく、Puppet Serverにもカタログにもシークレットを一切残さない、モダンでセキュアな「Deferred（遅延評価）関数」を使った連携術を解説します。
これをマスターすれば、あなたの管理するインフラは「パスワードの漏洩リスクほぼゼロ」の強固なものになりますよ。一歩ずつ、一緒に進めていきましょう！
—
1. なぜ「Deferred（遅延評価）」なのか？ 従来の連携との決定的な違い
具体的な設定に入る前に、まずは設計思想の「深淵」を少しだけ覗いてみましょう。
従来のPuppetとVaultの連携では、Puppet Server（マスタ）がコンパイル時にVaultからシークレットを取得し、それを「カタログ」という適用指示書に埋め込んでAgent（ターゲットノード）に送信していました。
【従来の方式】
[Vault] ──(シークレット)──> [Puppet Server] ──(カタログに埋め込み)──> [Puppet Agent]
▲ カタログに生パスワードが残るリスク！
この方式だと、Puppet Serverのメモリやディスク、さらにはAgent側の中間キャッシュ（カタログファイル）に生シークレットが書き込まれてしまうリスクがありました。
そこで登場したのが、Puppet 6以降でサポートされた「Deferred（遅延評価）機能」です。
【Deferred（遅延評価）方式】
[Puppet Server] ──(「ここをVaultから取得せよ」という指示書)──> [Puppet Agent]
│
(API呼び出し)
▼
[Vault]
(生シークレット)
この方式では、Puppet Serverはシークレットそのものを知りません。代わりに「Agentが適用する直前に、Agent自身がVaultからデータを取ってきて、メモリ上だけで展開し、ファイルに書き込みなさい」という「遅延評価関数（Deferred）」をカタログに埋め込みます。
これにより、カタログにはシークレットが一切残りません。これこそが、現代のエンタープライズIaCにおける究極のセキュリティデザインです。
—
2. 全体アーキテクチャとAppRole認証
Agentが直接Vaultにアクセスするためには、Agent自身がVaultに対して認証を通す必要があります。これにはVaultのAppRole認証を使用します。
AppRoleは「マシン（サーバーやコンテナ）のためのID/パスワード」のようなものです。
- RoleID: ユーザー名に相当（比較的公開されても安全）
- SecretID: パスワードに相当（厳重に管理が必要）
セキュアなパイプラインの裏技：Response Wrapping
「SecretIDをAgentにどうやって安全に渡すか？」という鶏と卵の問題があります。
ここで役立つのが、Vaultの「Response Wrapping（レスポンスラッピング）」という機能です。
Puppet Server、あるいはプロビジョニングツールが一時的な「使い捨ての引換券（Wrapping Token）」を発行し、Agentはそれを使ってVaultから1回限り有効なSecretIDを取り出します（アンラップ）。万が一途中で盗まれても、1回使われたら無効になるため、極めて安全です。
今回はこの思想をベースに、シンプルなHello World構成を作ってみましょう！
—
3. ステップ1：Vault側のセットアップ
まずはVault側で、Puppet Agentがシークレットを取得するためのポリシーとAppRoleを作成します。
3.1. シークレットの準備
テスト用に、Vaultにデータベースのパスワードを登録しておきます。
KV（Key-Value）シークレットエンジンを有効化
vault secrets enable -path=secret kv-v2
テスト用パスワードの書き込み
vault kv put secret/data/mysql_password value=”SuperSecretPassword2026!”
3.2. ポリシーの作成
Puppet Agentがこのパスワード「だけ」を読み取れる最小権限のポリシー `puppet-agent-policy.hcl` を作成します。
puppet-agent-policy.hcl
指定したパスのシークレットの読み取りのみを許可
path “secret/data/mysql_password” {
capabilities = [“read”]
}
このポリシーをVaultに登録します。
vault policy write puppet-agent-policy ./puppet-agent-policy.hcl
3.3. AppRoleの作成と設定
次に、AppRoleを有効化し、ポリシーを紐づけたロール `puppet-agent-role` を作成します。
AppRole認証を有効化
vault auth enable approle
ロールの作成（Tokenの有効期限は短めに設定：ここでは1時間）
vault write auth/approle/role/puppet-agent-role \
secret_id_ttl=”60m” \
token_num_uses=10 \
token_ttl=”10m” \
token_max_ttl=”30m” \
policies=”puppet-agent-policy”
3.4. RoleIDとSecretIDの取得
セットアップ用に、RoleIDとSecretIDを発行します。
RoleIDの取得
vault read auth/approle/role/puppet-agent-role/role-id
出力例: 12345678-abcd-ef01-2345-6789abcdef01 (これを控えます)
SecretIDの発行
vault write -f auth/approle/role/puppet-agent-role/secret-id
出力例: 87654321-dcba-10fe-5432-10fedcba9876 (これを控えます)
—
4. ステップ2：Puppet Agent側のモジュール導入と設定
今回はPuppet Agentが直接Vaultへ問い合わせを行うため、Agentノード側でVaultと通信できるモジュールをセットアップします。
Puppet公式/コミュニティで広く使われている `voxpupuli/vault` モジュール、あるいはシンプルなカスタム関数を使用します。ここでは、最も直感的でトラブルの少ない、Puppet標準の `deferred` 機能と、HTTPリクエストを投げるための設定を行います。
4.1. `puppet-vault` モジュールのインストール
Puppet Server（またはスタンドアロン環境）でモジュールをインストールします。
puppet module install voxpupuli-vault
4.2. Agentノードに認証情報を配置する
本番環境では、プロビジョニング時（User-dataなど）に動的にこのファイルを生成させますが、まずは手動でAgentノードの `/etc/puppetlabs/vault.conf` に認証情報を配置してみましょう。
{
“vault_addr”: “https://vault.example.com:8200”,
“auth_method”: “approle”,
“role_id”: “12345678-abcd-ef01-2345-6789abcdef01”,
“secret_id”: “87654321-dcba-10fe-5432-10fedcba9876”
}
※このファイルの権限は `root:root` かつ `0600` にして、Puppet Agentのプロセス以外から読めないように厳重に保護してください。
—
5. ステップ3：マニフェストの実装（Deferred関数のマジック）
いよいよ、心臓部となるマニフェスト（`init.pp`）の執筆です。
ここでは、`Deferred` 関数を使って「カタログの生成時ではなく、ターゲットでの適用時にVaultからデータを取得する」コードを書きます。
/etc/puppetlabs/code/environments/production/manifests/site.pp
node ‘target-node.example.com’ {
# 1. Vaultからシークレットを取得する処理を「遅延評価（Deferred）」として定義
# ‘vault_lookup::lookup’ は voxpupuli-vault モジュールが提供する関数です。
$dynamic_password = Deferred(‘vault_lookup::lookup’, [
‘secret/data/mysql_password’, # 取得したいVaultのパス
‘https://vault.example.com:8200’ # Vaultサーバーのアドレス
])
# 2. シークレットを使用した設定ファイルの生成
# ここがポイントです！
# カタログがコンパイルされる段階では、$dynamic_password の中身は空（Deferredオブジェクト）です。
# そのため、Puppet Serverのログやカタログキャッシュにパスワードは一切流出しません。
file { ‘/etc/mysql/conf.d/secret.conf’:
ensure => file,
owner => ‘root’,
group => ‘root’,
mode => ‘0600’, # 機密情報なので厳しく制限
content => Deferred(‘inline_template’, [
“#[Generated by Puppet]\n[client]\npassword=<%= @password %>\n”,
{ ‘password’ => $dynamic_password } # 適用直前にここでバインドされる！
]),
}
}
コードの解説
- `Deferred(‘vault_lookup::lookup’, […])`:
通常なら `vault_lookup::lookup(…)` と直接書くところを、`Deferred` というラッパー関数で包んでいます。これにより、「今すぐ実行するな、Agent側でこのリソースを適用する直前まで実行を遅らせろ」という指示に変わります。
- `inline_template` の遅延評価:
テンプレートの展開自体も `Deferred(‘inline_template’, …)` で囲む必要があります。そうしないと、テンプレートエンジンが「まだ空っぽの変数」を評価しようとしてエラーになってしまうからです。
—
6. ステップ4：Hello World！動作確認
それでは、動作確認をしてみましょう！
ターゲットとなるPuppet Agentノードで、以下のコマンドを実行してPuppetを適用します。
Puppet Agentを実行
puppet agent -t
実行ログの確認
成功すると、以下のようなクリーンな出力が得られます。
Info: Using configured environment ‘production’
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for target-node.example.com
Info: Applying configuration version ‘1710240000’
Notice: /Stage[main]/Main/Node[target-node.example.com]/File[/etc/mysql/conf.d/secret.conf]/ensure: defined content as ‘{sha256}e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855’
Notice: Applied catalog in 0.45 seconds
注目してください！
`Notice:` の部分に、生のパスワード（`SuperSecretPassword2026!`）は一切表示されていません。ハッシュ値のみが表示されています。
では、実際に生成されたファイルを確認してみましょう。
cat /etc/mysql/conf.d/secret.conf
出力結果:
[Generated by Puppet]
[client]
password=SuperSecretPassword2026!
見事に、ターゲットノード上でのみ、安全にVaultから動的シークレットが注入されてファイルが生成されました！
—
7. 【極限の知見】運用の現場で震えるほど役立つアドバイス
最後に、あなたが現場で実際にこのシステムを運用していく上での「プロの知見」をいくつかお伝えしますね。
① セキュリティの「最小特権」を維持せよ
AppRoleの `SecretID` や `Token` には、必ず TTL（有効期限） と 使用回数制限（num_uses） を設定してください。もしAgentサーバーが侵害されても、その認証情報が数分〜数時間で自動的に無効化されれば、被害を最小限に食い止めることができます。
② シークレットの変更検知と自動サービス再起動
「Vault側のパスワードが変更されたら、Puppetはどう動くの？」
Puppetは冪等性（べきとうせい）を担保するツールです。次回のPuppetエージェント実行時（デフォルトでは30分ごと）、Vaultから取得した値が以前と異なっていれば、Puppetは自動的にファイルを書き換え、関連するサービス（MySQLなど）を再起動（`notify`）してくれます。
file { ‘/etc/mysql/conf.d/secret.conf’:
# … (略) …
notify => Service[‘mysql’], # パスワードが変わったらMySQLを自動再起動！
}
これにより、手動でのパスワード変更作業や、それに伴う再起動漏れのミスから完全に解放されます。
—
まとめ：安全なIaCがもたらす、開発者と運用者の「心の平穏」
お疲れ様でした！
今回はPuppetとHashiCorp Vaultを「Deferred関数」を使って統合する、極めてセキュアな構成を構築しました。
この仕組みを導入することで、
1. GitHubにシークレットが漏洩するリスクが完全にゼロになる
2. Puppet Server（マスタ）のセキュリティ境界を強固に保てる
3. パスワード変更（ローテーション）が全自動で追従する
という、モダンインフラにおける究極の安心感を手に入れることができます。
最初は設定項目が多く感じるかもしれませんが、一度このパイプラインを組んでしまえば、毎日のシークレット管理が劇的に楽になりますよ。ぜひ、あなたの現場でも試してみてくださいね。
何かわからないことがあれば、いつでも聞いてください。スマートで安全なインフラを、一緒に作っていきましょう！