プロンプトとコンテキスト
マルチテナントの Kubernetes クラスターにおいて、あるサービスが内部 API を呼び出すために mTLS を使用する必要があります。アプリケーションはファイルの読み取りは可能ですが、Kubernetes API を呼び出したり、イメージ内に長期間有効な秘密鍵を保持したりしてはなりません。証明書の要求、署名、プロジェクション、ローテーション、失効、および監査を行う完全な PodCertificateRequest パスを設計してください。
面接官が評価するポイント
- PodCertificateRequest、従来の CertificateSigningRequest、および signer の責務を適切に分離できているか。
- kubelet による projected volume が鍵、証明書、およびトラストルートをどのように分離するかを説明できるか。
- signer の認可、テナント境界、ローテーションウィンドウ、Pod の削除、およびノードの侵害に対応できているか。
- PodCertificateRequest が v1.35 ではベータ版かつデフォルトで無効であり、v1.36 では明示的な有効化が必要であることを認識しているか。
確認すべき明確化のための質問
- 証明書はクライアント認証、サーバー認証、相互 mTLS のいずれを目的としていますか？
- どの SAN、有効期限、トラストルート、および失効セマンティクスが必要ですか？
- クラスターのバージョン、feature gate、ランタイム設定、および kubelet は Pod 証明書のプロジェクションをサポートしていますか？
- アプリケーションは証明書の有効期限が切れる前に、ファイルを再度開くことやディレクトリの変更を監視（watch）することができますか？
30秒の回答フレームワーク
kubelet が Pod に代わって証明書を要求するように設計します。signer は認可された signer と制約された ID フィールドのみを受け入れ、読み取り専用の projected volume を介して鍵、証明書、トラストルートを提供します。アプリケーションは API を呼び出すのではなくファイルを読み取り、ローテーション時にそれらを再読み込みします。要求、発行、プロジェクション、更新は監査可能であり、障害時には有効な古い証明書を維持するか新しい接続をブロックします。PodCertificateRequest は v1.35 でベータ版かつデフォルトで無効であり、v1.36 では feature gate とランタイム設定が必要であるため、機能検出とノードプール単位のカナリアリリースから開始します。
ステップごとの詳細解説
1. アイデンティティと認可境界の定義
Pod は目的と対象の signer を宣言しますが、任意の CA を選択することはできません。アドミッションポリシーによって namespace、service account、Pod ラベル、および許可された signer がバインドされ、signer は要求元、SAN テンプレート、鍵アルゴリズムを検証し、テナントをまたぐサブジェクトを拒否します。API アクセスは kubelet とコントロールプレーンコンポーネントに限定され、アプリケーションにはファイル読み取りアクセスのみが付与されます。
2. 要求およびプロジェクションパスの設計
kubelet が Pod 要求を作成し、署名された結果を取得します。秘密鍵はノード上で生成されるため、イメージやビジネス API に入ることはありません。証明書、鍵、およびトラストバンドルは、最小権限で個別にマウントされます。プロジェクションにはアトミックな置き換えが使用されるため、アプリケーションが部分的に書き込まれたファイルを読み取ることはありません。signer 名、有効期限、SAN は監査属性として記録されます。
3. ローテーション、失効、および障害の処理
有効期限が切れる前に更新を行い、kubelet の再起動、ネットワーク切断、一時的な CA の停止に対応します。新しいチェーンが検証されるまで古い証明書を保持し、読み込みに失敗した場合は新しい接続を拒否して健全性シグナルを公開します。Pod の削除、service account の変更、またはノードの再利用後にプロジェクションを削除します。失効は CRL、OCSP、短期間の有効期限など CA の契約に依存し、Kubernetes はすべての signer に対して単一の共通の失効動作を提供するわけではありません。
4. バージョン計画と可観測性
デプロイ前に、v1.35 でのベータデフォルト無効状態、v1.36 の feature gate とランタイム設定、および signer と kubelet の互換性マトリックスを確認します。要求のレイテンシ、発行失敗、残存有効期限、ローテーション成功、権限エラー、予期しない SAN を監視します。ログには要求の UID、namespace、Pod、signer、結果を含めるべきであり、秘密鍵や完全な証明書本文を含めてはなりません。カナリアデプロイ中は、短期間有効なレガシープロジェクションパスとロールバックスイッチを維持します。
質の高い回答例
Pod 証明書は、kubelet が仲介する短期間の ID 認証情報として扱います。アドミッションによって namespace と service account が許可された signer にバインドされ、signer は SAN、アルゴリズム、有効期限、テナント境界を検証します。鍵はノード上で生成され、証明書、鍵、トラストルートは個別の読み取り専用 projected ファイルとして提供されます。アプリケーションは API を決して呼び出しません。ディレクトリを監視するか要求ごとにファイルを再度開き、新しいチェーンを検証した後にのみアトミックに切り替えます。ローテーションは早い段階で開始されます。一時的な障害が発生した場合は有効な古い証明書を保持し、期限切れや ID 変更時には新しい接続をブロックしてアラートを発報します。Pod が削除されるとプロジェクションも削除され、失効は短期間の有効期限または CRL/OCSP に関する signer の契約に従います。ロールアウト前に、v1.35 のベータデフォルト無効状態と v1.36 の feature gate およびランタイム設定を確認し、要求 UID、signer、レイテンシ、失敗率、残存有効期限を記録しながらノードプールごとにカナリアリリースを実施します。
よくある間違い
- 任意の CSR を作成できる Kubernetes API トークンをアプリケーションに付与してしまう。
- 要求元が任意の signer、SAN、または namespace をまたぐサブジェクトを選択できるようにしてしまう。
- ノードの権限を無視したまま、秘密鍵をイメージ、ConfigMap、または長期間有効な Secret に配置してしまう。
- 起動時にのみ証明書を読み取り、ローテーション後も期限切れのファイルディスクリプタを使用し続けてしまう。
- すべてのクラスターバージョンでベータ機能が有効かつ安定しているものとして扱ってしまう。
- 完全な PEM データ、秘密鍵、またはテナントの機密に関わる監査フィールドをログに出力してしまう。
フォローアップの質問と回答
なぜ長期間有効な Secret を使用しないのですか？
長期間有効な Secret は露出ウィンドウを広げ、Pod のアイデンティティや削除へのバインドが困難になります。kubelet によるプロジェクションとローテーションを備えた短期間の証明書は認証情報の有効期間を短縮しますが、signer の失効およびリカバリの契約は明示的に定義しておく必要があります。
侵害されたノードの影響をどのように制限しますか？
ノードから Pod ディレクトリおよびコンテナユーザーへのアクセスを制限し、短い有効期間と最小限の SAN を使用し、価値の高いアイデンティティは分離された signer やハードウェアで保護された signer の背後に配置します。監査と異常接続の検出により対応時間を短縮します。
feature gate が無効になっている場合はどうしますか？
deployment controller に API リソース、ランタイム設定、および kubelet 機能を検出させます。前提条件が満たされていない場合は、ワークロードを一時停止するか、監査されたレガシーパスに切り替えます。有効に見えるもののローテーションされないファイルを暗黙的に作成してはなりません。