プロンプトとスコープ
このバックエンドに関する質問では、証明書のライフサイクルとサービス間通信の境界についての理解が試されます。重要なのは単にすべてのマシンに新しい証明書をコピーすることではなく、発行、信頼の更新、接続の置き換え、およびロールバックにおいて時間的な重複を持たせることです。
面接官が見ているポイント
- リーフ証明書、トラストバンドル、ルートCAの各移行の違いを明確に区別できているか。
- 長時間持続する接続（ロングリーブド接続）、キャッシュ、クロックスキュー、同時更新、およびノードの部分的障害を適切に処理できるか。
- コンテナイメージや環境変数に秘密鍵を埋め込むのではなく、短期間有効なワークロードIDを利用しているか。
- カナリアリリース、受け入れ検証、ロールバック、および有効期限アラートを定義できるか。
確認すべき質問事項
サービス検出、短時間接続と長時間接続の比率、発行者（Issuer）、クラスタ間またはドメイン間の信頼関係、クライアントによる鍵のロード方法、最大リクエスト/接続寿命、そして2つのルートまたは証明書の共存が可能かどうかを確認します。対象がリーフ証明書、中間CA、または信頼ドメイン全体なのかを明確にします。
30秒で答えるフレームワーク
私はローテーションを「信頼の確立」、「証明書の発行」、「段階的な接続の置き換え」の順に分割します。まず、すべての検証側が新旧両方のルートを受け入れるようにし、その後、新しいチェーンで短期間有効なリーフ証明書を発行します。クライアントやプロキシは新しいキーペアをアトミックにロードし、接続がドレインされるまで古いマテリアルを保持します。カナリアの実行中は、ハンドシェイクの失敗、証明書の有効期間、バンドルのバージョン、リトライ状況を監視します。異常が発生した場合は発行を停止して以前のパスに戻し、ロールバックとして証明書の検証を無効化することは決してしません。
ステップごとの解決策
1. アイデンティティと信頼ドメインの確立
各ワークロードに安定したSPIFFE IDまたは同等のアイデンティティを付与し、本番環境、ステージング環境、個別の信頼ドメインを分離します。検証側はトラストバンドルを保持し、発行者は承認されたワークロードの構成証明（Attestation）後にのみ署名します。ワークロード自身が秘密鍵を生成してアクセスを制限すべきであり、コントロールプレーンがアプリケーション設定を介して長期的な秘密鍵を配布してはなりません。
2. まず互換性のあるトラストバンドルを公開する
ルートCAまたは中間CAの移行では、デュアルルートのトラストバンドルを公開し、検証側がその新しいバージョンをロードしたことを確認します。古い証明書と長時間持続する接続がまだ存在するため、古いルートをすぐに削除してはいけません。新しい証明書の発行を開始する前に、バンドルのバージョン、ロードの成功状況、および古い状態のインスタンスを追跡します。
3. 新しい証明書の発行とロード
ワークロードはWorkload API、サイドカー、または同等の動的インターフェースを介して短期間有効なX.509アイデンティティを取得します。余裕を持った早期の期間内に更新し、鍵と証明書をアトミックに置き換えます。読み取り側からは常に古いペアか新しいペアのいずれかが見え、混ざった状態にはなりません。失敗した場合は直前の有効なマテリアルを保持してリトライし、期限切れの証明書を無制限に延長してはいけません。
4. 接続とリクエストの境界の処理
新しい証明書は通常、新しいTLSセッションに影響を与えますが、長時間接続は古い証明書を維持する可能性があります。HTTP/2、gRPC、またはデータベースプールに対して最大接続期間（max connection age）を設定し、新しいハンドシェイクが成功した後に古い接続をグレースフルにドレインします。ローテーションがリトライスパイクに拡大しないよう、リトライは冪等性、タイムアウト、およびバックオフを遵守する必要があります。
5. カナリア、ロールバック、ルート削除の設計
まず1つのワークロードプールと1つのトラフィックパスで検証し、その後リージョンやサービスごとに展開を拡大します。ロールバックでは新しい発行を停止し、古いバンドルと接続ポリシーを復元します。古い証明書と接続がすべてドレインされた後にのみ、古いルートを削除します。新しいルートの秘密鍵が侵害された場合、緊急の失効と隔離は通常のローテーションワークフローから独立して実行できなければなりません。
6. 障害の可観測性とリハーサル
証明書寿命のパーセンタイル、発行失敗、SVIDまたはバンドルの更新遅延、TLSハンドシェイクエラー、アイデンティティとバージョンでグループ化された4xx/5xx、およびドレイン所要時間を監視します。期限切れアラート、クロックスキュー、コントロールプレーンの停止、および更新できないリージョンのシナリオをテスト用アイデンティティでリハーサルします。ログにはアイデンティティ、バージョン、結果のみを記録し、秘密鍵は決して記録しません。
質の高い模範解答
私ならまず、これがリーフ、CA、または信頼ドメインのどのローテーションであるかを特定し、各ワークロードに安定したアイデンティティと短期間有効なX.509 SVIDを付与します。CA移行の場合、デュアルルートのトラストバンドルを公開し、Workload APIやプロキシを介して新しいリーフ証明書を動的に発行する前に、検証側がそれをロードしたことを確認します。鍵と証明書はアトミックに置き換え、有効な古いマテリアルを保持します。新しい接続には新しい証明書が使用され、HTTP/2やgRPCの接続は制限された最大期間でドレインされます。ワークロードプールおよびリージョン単位でロールアウトし、ハンドシェイクエラー、バンドルバージョン、残り有効期間、およびリトライ率を監視します。障害発生時は発行を停止し、古いバンドルと接続ポリシーを復元します。検証を無効化することは決してしません。古い証明書と接続がドレインされた後にのみ、古いルートを削除します。テスト用アイデンティティを用いて有効期限切れ、クロックスキュー、コントロールプレーン障害のリハーサルを行い、イメージ、環境変数、ログに秘密鍵が入らないようにします。
よくある間違い
- 新しいルートを公開する前に古いルートを削除し、古い証明書をまだ使用しているノードを破壊してしまう。
- 長時間接続、プール、およびインフライトリクエストを処理せずにファイルのみを置き換える。
- 秘密鍵をコンテナイメージ、環境変数、または通常の設定ストアに埋め込む。
- 鍵と証明書を別々に切り替えて、不一致のペアを作成してしまう。
- 障害発生時にTLS検証を無効化したり、期限切れの証明書を無期限に延長したりする。
- バンドルバージョン、ハンドシェイク、更新遅延のテレメトリがなく、直前の有効期限アラートしかない状態にする。
フォローアップの質問と回答
なぜ最初にバンドル内で新旧両方のチェーンを受け入れる必要があるのか？
古い証明書が機能し続けている間に検証側が新しいルートを学習するため、発行と検証の間にギャップが生じません。古いルートを使用している証明書と接続がドレインされた後にのみ、古いルートを削除します。
更新後、長時間接続はどうなるのか？
最大接続期間を設定し、グレースフルにドレインして、新しい接続がハンドシェイクを完了した後にクローズします。リトライ可能なリクエストは依然として冪等性とバックオフのルールに従う必要があり、すべてのクライアントを一度に再接続させてはいけません。
コントロールプレーンが一時的に利用不能になった場合、サービスは即座に停止するのか？
いいえ。アイデンティティとバンドルが有効である間はキャッシュし、早期に更新を行い、残り有効期間についてアラートを発報します。キャッシュは無期限のバイパスになるのではなく、明示的なセキュリティおよびコンプライアンス上の制限を持つ必要があります。
どのサービスも古いルートに依存していないことをどのように証明するか？
アイデンティティ、証明書チェーン、およびバンドルバージョンごとにハンドシェイクとロードを記録し、観察期間中に古いチェーンの使用がゼロであることを確認します。更新されたと推測するのではなく、レポートできないノードを隔離するかロールバックします。