【SREの極意】Hieraの「平文の呪縛」を解く：Puppetにおけるセキュアなシークレット管理の深淵
Puppetを使っている多くのチームが、ある日突然直面する壁がある。「パスワードやAPIキーをどこに置くか？」という問題だ。HieraのYAMLに平文で書き込み、Gitリポジトリにプッシュする……。それは、「自分の家の鍵を玄関マットの下に隠して、その地図をSNSで公開する」のと同じレベルの自殺行為だ。
今日は、IaCの守護者として、Puppetのシークレット管理を「妥協なきレベル」まで引き上げる実装論を語る。
—
1. なぜ「Hiera-eyaml」が標準なのか：暗号化の境界線
まず、シークレットマネジメントの基本原則は「コードと設定を分離し、データは常に暗号化状態でリポジトリへコミットする」ことにある。そのためのデファクトスタンダードが `hiera-eyaml` だ。
なぜHashiCorp Vaultではなくeyamlか？
小規模〜中規模の構成なら、まずは `eyaml` から始めるべきだ。Vaultは運用コスト（可用性、認証、トークン管理）が重い。まずは「暗号化されたHieraデータ」をGitで管理し、CI/CDパイプラインと同期させる方が、開発スピードを損なわない。
実装の勘所:
- PKCS#7暗号化: 公開鍵/秘密鍵ペアを使用する。秘密鍵は Puppet Server のみに配置し、Puppet Agent には決して渡さない。
eyaml で暗号化した値の例
ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAw…]
db_password: >
ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAw…]
—
2. SREが愛する「高速化」の極意：生産性を底上げするツール群
ただコードを書くのではない。「速く、安全に書く」ための環境構築が重要だ。
必須プラグイン & 設定
1. VS Code 拡張機能 `Puppet`: これなしで Puppet は書けない。
2. `eyaml-cli` のエイリアス: ターミナルでいちいちコマンドを打つのは無駄だ。`.zshrc` に以下の関数を仕込んでおけ。
秘密鍵の場所を指定して一発で暗号化する関数
function eyaml_enc() {
eyaml encrypt -o string -s “$1” -k /etc/puppetlabs/puppet/keys/public_key.pkcs7.pem
}
- 使い方は至極単純: `eyaml_enc “my-secret-password”` と打つだけで、クリップボードに貼れる形式で暗号化文字列が吐き出される。
—
3. Hiera YAMLの「神」構成：メンテナンス性を最大化する
Hieraのデータがスパゲッティ化しているなら、それは設計の敗北だ。以下のディレクトリ構造を強制せよ。
data/
├── common.yaml # 非機密なグローバル設定
├── nodes/ # ノードごとの個別設定
│ └── web-01.yaml
├── secrets/ # 暗号化した値のみを分離する
│ └── production.eyaml
└── hiera.yaml # ルックアップの優先順位を明確に
hiera.yaml のベストプラクティス:
version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:
- name: “Secrets”
lookup_key: eyaml_lookup_key
paths:
- “secrets/%{::environment}.eyaml” # 環境ごとのシークレット分離
options:
pkcs7_private_key: /etc/puppetlabs/puppet/keys/private_key.pkcs7.pem
- name: “Per-node data”
path: “nodes/%{::trusted.certname}.yaml”
- name: “Common”
path: “common.yaml”
—
4. チーム開発における「絶対ルール」
優秀なテックリードとして、以下の3つをチームの掟（ルール）にしている。
1. コミット前の自動チェック: `pre-commit` フックを使って、`.eyaml` 以外のファイルに「BEGIN RSA PRIVATE KEY」や「password:」といった文字列が含まれていないかRegexでチェックさせる。
2. 鍵のローテーション: PKCS#7の鍵は四半期に一度必ず再生成する。Puppet Serverの全コンパイルノードに新しい鍵を配布するスクリプトを準備しておくこと。
3. No-More-Plaintextポリシー: Gitリポジトリ内に平文のパスワードを見つけた瞬間、そのブランチは即座にマージ不可とし、対象の全履歴を `git filter-repo` で抹消するまでが「修正」であると教え込む。
—
結論：技術的負債を抱えるな
Puppetは古いツールではない。「成熟した、最も信頼できるIaCの基盤」だ。
シークレット管理を適切に行うことは、単なるセキュリティ対策ではなく、「インフラコードを安心して自動化し続けるためのエンジニアリング上の投資」である。
次にPuppetのコードを書くとき、その「平文」が将来の自分を追い詰める負債にならないか、もう一度考えてほしい。我々SREの仕事は、コードを動かすことではなく、「コードが常に安全に動く仕組み」を構築することなのだから。
もし、Vaultへの完全移行を検討するフェーズに来ているなら、次は `hiera-vault` バックエンドの設計について深掘りしよう。だがまずは、この `eyaml` の確実な運用から始めてくれ。現場からは以上だ。