【実務・中級編】Chefでシークレット情報を安全に管理する！encrypted_data_bagの使い方とAWS Secrets Manager連携 – インフラ構成管理（IaC）活用バイブル

Chefによるシークレット管理の極致：Encrypted Data BagsからAWS Secrets Managerへの脱却まで

Chefを使っている多くの現場で、いまだに「Gitリポジトリにコミットされた暗号化済みData Bag」が技術負債として鎮座しているのを見かける。かつてはベストプラクティスだったかもしれない。だが、現代のクラウドネイティブな環境において、静的な秘密鍵を管理し続けることは、単なる運用コストの増大であり、セキュリティ上の大きな穴だ。

今日は、Chefにおけるシークレット管理の「過去・現在・未来」を総括し、実戦で明日から使えるプロの知見を授ける。

—

1. Encrypted Data Bagsの限界と「現代の落とし穴」

Chefの`encrypted_data_bag`は、対称鍵による暗号化で平文保存を回避する仕組みだ。しかし、これには運用を破綻させる決定的な弱点がある。

鍵のローテーションが地獄: `secret`ファイル自体をどう配布・管理するか。CI/CDパイプラインに埋め込むと、結局そこが単一障害点になる。
権限分離の欠如: 鍵さえあれば誰でも復号できる。開発者とCIツール、本番サーバーでアクセス権限を細かく制御できない。

現場で震える運用ルール：Chefの秘密鍵を扱う際の作法

もし、どうしてもData Bagを使わざるを得ない場合でも、以下のルールは鉄則だ。

1. 鍵は決してリポジトリに入れない: 鍵はAWS S3のKMS暗号化バケットや、HashiCorp Vaultに隔離せよ。
2. Chef-Vaultの使用は検討したか: 標準のData Bagよりも、Chef-Vaultを使うべきだ。これは特定のノードだけに復号権限を与えることができるため、Data Bagよりもはるかにセキュアだ。

—

2. AWS Secrets Manager連携：Chefの「次世代」運用

Chefのレシピ内で動的にシークレットを注入するなら、AWS Secrets Managerを利用するのが現在の最適解だ。ChefのノードがIAMロールで保護されていれば、パスワードをリポジトリに保存する必要は一切なくなる。

ベストプラクティス：カスタムリソースによる抽象化

レシピ内に直接AWS SDKを書くのはNGだ。以下のようなカスタムリソースを作成し、各レシピからは「呼び出すだけ」の状態にする。

libraries/secret_helper.rb
Chefのレシピ内でSecrets Managerから値を取得するヘルパー
require ‘aws-sdk-secretsmanager’

module SecretsHelper
def fetch_secret(secret_id)
client = Aws::SecretsManager::Client.new(region: ‘ap-northeast-1’)
resp = client.get_secret_value(secret_id: secret_id)
JSON.parse(resp.secret_string)
end
end
Chef::Recipe.send(:include, SecretsHelper)

レシピでの利用例

recipes/db_config.rb
db_secrets = fetch_secret(‘production/db/credentials’)

template ‘/etc/myapp/db.conf’ do
source ‘db.conf.erb’
variables(
username: db_secrets[‘username’],
password: db_secrets[‘password’] # 平文はどこにも存在しない
)
sensitive true # Chefのログにパスワードが出ないよう必ず設定
end

重要: `sensitive true`を忘れるな。Chefのログ出力にシークレットが混入すると、即座にセキュリティインシデントだ。

—

3. 生産性を劇的に高める「プロのChef開発環境」

Chefの開発は往々にして「適用して待つ」という遅延が発生しやすい。これを解消し、開発スピードを上げるためのTipsを共有する。

必須プラグイン：`chef-sugar`

ChefのDSLを拡張する神ライブラリだ。例えば、「Amazon Linux 2か、それ以外か」といった条件分岐が劇的に簡潔になる。

chef-sugarがあればこんなに短く書ける
if rhel? && node_platform_version.to_i >= 7
# 複雑なバージョン判定を排除
end

開発を爆速にするキーボードショートカット (VSCode)

`Ctrl + Shift + P` -> `Chef: Run Kitchen Test`: 変更したら即座にTest Kitchenを走らせる。思考を止めないためにキーバインドをショートカットに割り当てること。
`Ctrl + Alt + L` (フォーマット): Chefのコードスタイルを統一する。チーム開発において、コードレビューでインデントの議論をするのは時間の無駄だ。`rubocop`と連動させよ。

—

4. チーム開発における設定共有の掟

設定ファイル（`attributes/default.rb`など）は、階層化と検索順位を意識せよ。

Attributeは「値」を入れず「構造」を定義せよ:

`default[‘myapp’][‘db_password’] = ‘…’` ではなく、`default[‘myapp’][‘db_secret_path’] = ‘…’` とし、Secrets ManagerのIDを管理させる。

`.kitchen.yml`の標準化:

チーム全員で同じ環境（AMI、インスタンスサイズ）を共有するために、`kitchen.yml`をテンプレート化し、環境変数で動的に制御するルールを徹底せよ。

.kitchen.yml のベストプラクティス例
driver:
name: ec2
instance_type: t3.micro
# 開発用IAMロールの指定で権限管理を再現
iam_profile_name: chef-dev-profile

platforms:

name: amazonlinux-2

—

最後に：インフラをコードにする意味を問え

Chefでシークレットを安全に管理するということは、単にパスワードを隠すことではない。「インフラのライフサイクルから人的要因（ミス）を排除し、冪等性を担保した状態で自動化し続けること」こそが、SREとしての本質だ。

Encrypted Data Bagsに依存した古い体質を脱却し、Secrets ManagerやVaultのような動的シークレット管理へ移行せよ。それが、あなたのインフラを「壊れない」「狙われない」堅牢な城にする唯一の道だ。

コードは嘘をつかない。だが、設計は裏切る。常に最新の技術スタックで、Chefという強力な武器を研ぎ澄まし続けてほしい。