Chef Infra Serverの「マルチテナント」を極める：組織分離とRBACによるガバナンスの最適解
Chef Infra Serverを単なる設定管理ツールとして使っていないか？もし君のチームが「一つのChef Serverで全環境を管理し、権限が肥大化し、誰が何をしたかわからない」という状態に陥っているなら、それはChefの真の実力をドブに捨てているのと同じだ。
今回は、Chef Infra Serverにおけるマルチテナント運用の深淵――OrganizationsとRBACによる鉄壁の分離、そしてAPIクライアントの権限最小化という、実戦でしか得られない「現場の作法」を伝授する。
—
1. 組織（Organization）設計の黄金律：なぜ「混ぜるな危険」なのか
Chefにおいて、Organizationは単なる論理的なグループではない。「名前空間の境界」であり「セキュリティの防波堤」だ。
組織分離のベストプラクティス
- 環境単位の切り分け: `production`, `staging`, `sandbox` で分けるのは基本中の基本。さらに、プロダクトチーム単位で組織を分けることで、ノードの衝突を防ぎ、クックブックの公開範囲を物理的に隔離する。
- 共有クックブックの扱い: 組織間でコードを共有したい場合、コピーを繰り返すのは愚策だ。`Policyfile` を活用し、CI/CDパイプラインを通じて各組織のPolicy Groupへプロモートする設計にせよ。
2. RBAC（役割ベースのアクセス制御）の極致
Chef ServerのRBACは、Chef Automate（あるいはChef ServerのAPI経由）で細かく制御できる。ここで重要なのは「最小権限の原則」をどこまで突き詰められるかだ。
推奨される権限セット
- Developer: `read` 権限のみ。クックブックの閲覧は可能だが、ノードの削除やクライアントの鍵再発行は不可。
- SRE/Ops: `update`, `delete`, `grant` 権限。ただし、`admin`グループには極力入れない。
- CI/CD Pipeline (Service Account): 特定のClientとして登録し、そのClientに対してのみ対象リソースの書き込み権限を付与する。
/
- 最小権限を定義したACLのJSON例 (Chef Server API用)
- 特定のCIパイプライン用クライアントに「クックブックのアップロード」のみを許可する設定
/
{
“create”: [“pivotal”, “ci-pipeline-user”],
“read”: [“pivotal”, “ci-pipeline-user”, “developers”],
“update”: [“pivotal”, “ci-pipeline-user”],
“delete”: [“pivotal”],
“grant”: [“pivotal”]
}
3. 生産性を加速させる「神」環境設定
日常のオペレーションを劇的に速くするための、テックリードが仕込んでいる設定を紹介する。
必須プラグイン: `knife-acl`
RBACの管理をGUIで行うのは非効率極まりない。`knife-acl` を導入すれば、CLIから瞬時に権限を確認・変更できる。
権限の確認を瞬時に行う
knife acl show nodes web-server-01
隠れた生産性ハック: `.chef/config.rb` の自動化
`knife` コマンドを叩くたびにオプションを打つな。組織ごとに設定を切り替える環境変数を活用し、シェル関数でラッパーを作るのがプロの流儀だ。
.chef/config.rb のベストプラクティス
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name ENV[‘CHEF_NODE_NAME’]
client_key “#{current_dir}/#{ENV[‘CHEF_NODE_NAME’]}.pem”
chef_server_url “https://chef-server.internal/organizations/#{ENV[‘CHEF_ORG’]}”
cache_type ‘BasicFile’
cache_options( :path => “#{ENV[‘HOME’]}/.chef/checksums” )
4. 鍵ローテーションの完全自動化：セキュリティの自動化
「鍵の使い回し」はSREの恥だ。ノードのプロビジョニング時に一度だけ使われる `client.pem` は、初回ブート時に自動でローテーションされる仕組みを組み込むべきだ。
1. Chef Clientの実行時に `client_key_path` をテンポラリに設定。
2. 初回実行終了後、Chef Automate経由で該当クライアントの鍵を強制再生成。
3. セキュアなKMS（AWS KMSやHashiCorp Vault）経由で鍵を注入。
このサイクルを回せば、万が一鍵が漏洩しても、その影響範囲は最小限に抑えられる。
5. チーム開発で守るべき「掟」
最後に、チーム全体の生産性を下げないための共有ルールを記す。
1. Policyfileを神とせよ: `Berkshelf` は過去の遺物だ。依存関係の解決をロックし、テスト済みアーティファクトを各環境へデプロイするための唯一の正解は `Policyfile.rb` にある。
2. Chef Specの強制: クックブックのプルリクエストには、必ずテストの通過を必須とする。手動検証は一度でもやれば癖になる。
3. Metadataの自動生成: チームで `foodcritic` (現在は `cookstyle`) をCIに組み込み、構文の揺れをコードレベルで排除せよ。
—
最後に。
インフラの自動化は、単に「手作業を減らす」ことではない。「意図した通りの状態を、誰が実行しても確実に再現できる」という信頼を構築する作業だ。Chef Infra Serverのマルチテナント運用はその最前線にある。
君たちの組織が、Chefという強力なツールを真に使いこなし、インフラのストレスから解放されることを願っている。次は、君のコードでそれを示してくれ。