プロンプトとスコープ
プラットフォームチームはetcd内のSecretを保護する必要があります。クラスタには複数のkube-apiserver、外部KMSプラグイン、および多数の過去のオブジェクトが存在しますが、移行中もリリースを停止することはできません。設定、ローテーション、再書き込み、検証、監視、およびロールバックを設計してください。
面接官がテストしていること
- KMS v2のエンベロープ暗号化の境界とDEK/KEKの関係の理解。
- 暗号化された新規書き込みと再書き込みされた過去のオブジェクトの区別。
- 複数のapiserver、KMS障害、ローテーション、および同時更新の処理。
- 単なる設定の差分（config diff）ではなく、etcdのエビデンスとAPI読み取りによる結果の証明。
明確化のための質問
- どのKubernetesバージョン、プラグインバージョン、高可用性トポロジがデプロイされていますか？
- カスタムリソースや監査ログを含め、どのリソースが保護対象ですか？
- 外部KMSはどのような可用性、レイテンシ、ローテーション、ディザスタリカバリの保証を提供していますか？
- コントロールプレーンの移行ウィンドウ、ロールバック期限、およびどのようなコンプライアンスエビデンス形式が必要ですか？
30秒の回答
非本番クラスタでKMS v2プラグインと権限を検証します。KMSを第1プロバイダにし、旧プロバイダを読み取りフォールバックとして保持した上で、各kube-apiserverを1台ずつローリングアップデートします。新規の書き込みは暗号化されますが、過去のオブジェクトにはno-op更新またはストレージバージョン移行（storage-version migration）が必要です。API読み取り、etcdプレフィックス、KMSメトリクス、障害訓練、および監査ログを検証します。すべてのオブジェクトが再書き込みされ、ロールバックウィンドウが終了した後にのみ、旧プロバイダを削除します。
ステップバイステップ設計
1. 暗号化モデルの定義
Kubernetesはエンベロープ暗号化を使用します。データ暗号化キー（DEK）がリソースを保護し、キー暗号化キー（KEK）は外部KMSによって保護されます。KMS v2はサーバーサイドキャッシュとapiserverごとのDEK設計によってリクエストオーバーヘッドを削減しますが、etcd内のすべての古い値を自動的に再書き込みするわけではありません。
2. プラグインと権限を最初に検証
分離されたクラスタで、ソケット、ID、タイムアウト、再起動、およびKMS利用不可時の動作をテストします。kube-apiserverが旧プロバイダによって書き込まれたオブジェクトを復号できること、および新しいプロバイダ経由で新しいSecretを書き込めることを確認します。レイテンシ、エラー、キャッシュヒット、KMS呼び出し量を記録します。
providers:
- kms:
apiVersion: v2
name: external-kms
endpoint: unix:///var/run/kms/plugin.sock
- aescbc:
keys:
- name: old-key
secret: <base64-secret>3. 高可用性コントロールプレーンのローリングアップデート
KMSを先頭に配置し、読み取り用に旧プロバイダを維持して、kube-apiserverを1台ずつ再起動します。各変更後にAPIの読み取りと書き込み、同時リクエスト、および監査出力を検証します。コントロールプレーン全体を一度に再起動してはいけません。ロールバックのために設定とプラグインをバージョン管理します。
4. 過去のオブジェクトの再書き込み
プロバイダの順序変更は今後の書き込みにのみ影響します。Secretやその他の保護対象リソースに対してno-op更新をバッチ処理するか、ストレージバージョン移行を使用して再書き込みをトリガーし、競合が発生した場合はリトライします。APIサーバー、etcd、KMSに過度な負荷がかからないよう、名前空間でシャーディングし、レート制限を設け、オブジェクトのバージョンを記録します。
5. 暗号化エビデンスの収集
新しいSecretを作成し、etcdからrawバイトを読み取ってKMS v2の暗号化プレフィックスを検証します。次にAPI経由で読み取り、平文と比較します。古いオブジェクトやすべての保護対象リソースタイプをサンプリングし、まだ再書き込みされていないものをカウントします。API読み取りが成功しただけでは、ディスク上の値が暗号化されている証明にはなりません。
6. ローテーション、障害対応、ロールバック
KEKローテーション後は、復号のために古いKEKを利用可能な状態にしておき、バッチで再書き込みを行い、障害を監視します。KMSタイムアウト、ソケット喪失、1台のapiserverのロールバック、プラグインのアップグレードの訓練を実施します。エラー率がしきい値を超えた場合は、再書き込みを一時停止し、以前の読み取り設定を復元します。新しいパスと過去データの網羅性が証明された後にのみ、旧プロバイダを削除します。
模範的な高品質の回答
まず隔離された環境でKMS v2プラグイン、権限、レイテンシ、障害時の動作を検証します。本番環境ではKMS v2を先頭に設定し、読み取り用に旧プロバイダを一時的に保持した上で、kube-apiserverを個別にローリングアップデートします。新規書き込みが暗号化されたら、リソースと名前空間のバッチ境界を定めてオブジェクトを再書き込みし、進捗、競合、リトライを記録します。エビデンスにはAPI読み取り、etcdプレフィックス、サンプリングされた過去のオブジェクトを含めます。網羅性が完了した後にのみ旧プロバイダを削除します。ローテーションとKMS障害には、訓練、しきい値、およびスコープを定めたロールバックが必要です。
よくある間違い
- 古いオブジェクトを再書き込みせずに設定のみを変更する → 過去の平文が残る → バッチ更新と完了カウントを実施する。
- すべてのapiserverを一度に再起動する → コントロールプレーンの停止 → 1台ずつローリングし、健全性を観察する。
- API読み取りのみを確認する → ストレージ暗号化が証明されない → etcdのrawバイトを検査する。
- 旧プロバイダを直ちに削除する → 古いデータが復号できなくなる → 移行を待ち、ロールバックウィンドウを確保する。
- KMSのレイテンシとキャッシュを無視する → ピーク時のAPIリクエストがKMSを圧迫する → 負荷テスト、レート制限、呼び出し監視を実施する。
フォローアップの質問と回答
KMS v2設定後、新しいSecretはすべて安全ですか？
新規の書き込みには最初のプロバイダが使用されますが、古いオブジェクトは自動的には変更されません。それらを再書き込みし、etcdのエビデンスで検証してください。
KMSが利用できない間も書き込みを継続できますか？
プラグインのキャッシュと設定に依存します。常に利用可能であると仮定してはいけません。タイムアウト、書き込み拒否、アラート、および復旧後のリトライ動作を定義し、訓練を実施してください。
旧プロバイダの維持が恒久的な解決策ではなくリスクとなるのはなぜですか？
移行中やロールバック時の復号性を維持できますが、鍵と設定のスコープが広がります。網羅性が証明された後に削除し、ローテーションと復旧のエビデンスを保持してください。