プロンプトとスコープ
これはアイデンティティインフラストラクチャおよびバックエンドの信頼性に関する質問です。Kubernetes ServiceAccount は、API サーバーまたはそのアイデンティティを信頼する他のシステムにアクセスするために署名付き JWT を使用します。v1.36 では、外部 ServiceAccount トークン署名が安定版（stable）となり、署名リクエストがローカルの Unix ドメインソケット経由で API サーバーから外部へ出られるようになりました。設計では、TokenRequest、公開鍵検証、ローテーション、および高可用性のセマンティクスを維持しながら、秘密鍵の露出を低減する必要があります。
面接官が評価するポイント
- 単に「KMS に接続する」と言うだけでなく、署名、発行、検証、認可を明確に分離しているか。
- UDS/gRPC 接続の動作、デッドライン、並行性、リトライ、およびフェイルクローズ処理を設計しているか。
- 鍵の重複期間、JWT の
kid、キャッシュ、および検証側のリフレッシュを適切に処理しているか。 - 有効な短寿命トークンを早期に失効させることなく、ローテーションとロールバックを実行しているか。
- 監査、レイテンシ、エラー、および鍵使用状況のメトリクスを定義しているか。
確認すべき明確化の質問
- トークンの TTL、対象オーディエンス、発行 QPS、および API サーバーのレプリカ数はどれくらいか？
- 外部署名サービスは、HSM 保証、ヘルスプローブ、バージョニングされた鍵、および冪等性 ID を提供しているか？
- 検証側はどのように JWKS を取得し、リフレッシュの遅延やキャッシュ TTL はどのようになっているか？
- 署名サービスが利用できない場合、新規トークンの発行を拒否してよいか、それとも制御された旧鍵へのフォールバックが存在するか？
- ローテーション中にオフラインジョブやクラスター外のシステムがこれらの JWT に依存しているか？
30秒での回答
「私はパスを、TokenRequest の認可、API サーバーから外部署名サービスへの呼び出し、公開鍵の配布、および RBAC 認可に分割します。API サーバーは、デッドライン、リクエスト ID、制限付きリトライを備えた保護された Unix ソケット経由で署名サービスを呼び出し、秘密鍵は KMS または HSM の内部に留めます。ローテーション中は、新しい公開鍵を公開し、検証側が重複期間を持ってリフレッシュできるようにした上で、新しい kid で発行を開始し、古いトークンの TTL が切れた後にのみ古い鍵を廃止します。署名サービスが利用できない場合は、保護されていないトークンを暗黙的に作成するのではなく、新規発行を拒否してアラートを発報します。署名レイテンシ、拒否率、ソケットエラー、鍵 ID、JWKS の鮮度を計測し、ロールバックに備えて古い署名サービスと鍵を保持します。」
ステップごとの詳細解説
ステップ 1: 信頼とデータフローの定義
TokenRequest の認可は、誰がどの ServiceAccount およびオーディエンスに対してトークンをリクエストできるかを決定します。リクエストの検証後、API サーバーは JWT ペイロードを外部署名サービスに送信します。署名サービスは署名を返し、API サーバーはトークンを返します。発行者（issuer）、オーディエンス、有効期限、および RBAC のセマンティクスは引き続き API サーバーが保持します。外部システムは制御された署名のみを実行し、追加の権限を付与してはなりません。
ステップ 2: ローカル署名サービスインターフェースの設計
文書化された設定では、--service-account-signing-endpoint はバージョニングされた署名プロトコルを実行できる Unix ドメインソケットを指定します。ソケットのアクセス権限、ディレクトリ、プロセス ID、および SELinux や AppArmor のポリシーを API サーバーのみに制限します。リクエストには鍵のバージョン、アルゴリズム、ダイジェストまたは署名対象バイト列、リクエスト ID、およびデッドラインを含め、署名、kid、および監査相関 ID を返します。通常のログに秘密鍵や完全なトークンを決して出力してはなりません。
ステップ 3: デッドライン、リトライ、および冪等性の処理
署名はレイテンシに敏感なパスであるため、短いデッドラインと制限された並行性を使用します。一時的なネットワークや HSM の障害に対しては限定的なリトライを行う場合がありますが、無限のリトライは API サーバーのキューを増大させます。リクエスト ID は署名サービスと API サーバーの監査を関連付けます。プロトコルが冪等性キャッシュをサポートしている場合、二重計上を防ぐことができます。タイムアウト後は明示的なエラーを返し、新規発行を拒否します。既存のトークンが検証され続けるかどうかは、公開鍵と有効期限ポリシーに依存します。
ステップ 4: 鍵ローテーションと JWKS の重複期間の設計
新しい鍵を作成し、署名サービスがその新しい kid を使用できるように設定してから、新しい公開鍵を JWKS で公開します。検証側がリフレッシュされた後、その鍵で新しいトークンを発行します。最も長いトークン TTL にキャッシュおよびクロックスキュー（時刻のずれ）のウィンドウを加えた期間以上、古い公開鍵を保持します。発行者が切り替わったからといって、単に古い鍵を削除してはなりません。ローテーションは一時停止、監査、および取り消しが可能でなければなりません。
ステップ 5: レプリカとディザスタリカバリの維持
すべての API サーバーレプリカは、一貫した鍵バージョンと時刻を持つ、ローカルまたは高可用性の署名サービスにアクセスできる必要があります。中央集約型の署名サービスの場合は、ノード間ネットワーク、障害ドメイン、および影響範囲（blast radius）を評価します。ノードごとのサイドカーの場合は、HSM 接続と鍵配布が乖離しないようにします。署名サービスの再起動、ソケットファイルの欠落、HSM のスロットリング、JWKS の利用不可、および API サーバーのローリングアップグレードをテストします。
ステップ 6: 検証、監査、およびロールバック
カナリア API サーバーで設定を有効化し、TokenRequest の発行者、オーディエンス、kid、有効期限、および RBAC の動作を検証します。新旧の鍵、検証側のタイプ、およびクロックスキューをまたいだ統合テストを実行します。署名の p50/p95、失敗理由、ソケットレイテンシ、HSM カウント、JWKS の鮮度、およびトークン拒否率を追跡します。古い公開鍵を保持したまま古い署名サービスと鍵の設定を復元することでロールバックします。古いトークンと監査ウィンドウが終了するまでは、公開鍵を削除してはなりません。
高品質な回答例
「私は外部署名サービスを限定的な署名境界として位置づけます。API サーバーは引き続き TokenRequest、発行者、オーディエンス、有効期限、および RBAC を検証し、保護された Unix ソケット経由で署名サービスを呼び出し、秘密鍵は KMS または HSM のみに保持します。リクエストにはバージョン、kid、ID、デッドライン、および制限されたリトライを含め、署名サービスが失敗した場合は新規トークンを拒否してアラートを出します。ローテーションでは新しい JWKS を公開し、検証側のリフレッシュを待ち、新しい kid での発行に切り替え、最も長い TTL、キャッシュ、およびクロックスキューのウィンドウの間、古い鍵を保持します。すべてのレプリカは、一貫したローカルソケットアクセス、鍵バージョン、および時刻を持たなければなりません。カナリア環境ではレイテンシ、拒否率、鍵 ID の分布、JWKS の鮮度、および RBAC 統合を確認し、ロールバックでは古い署名サービスと公開鍵を維持します。」
よくある間違い
- 外部署名サービスに RBAC やオーディエンスの決定を任せ、その責務を拡大してしまう。
- 秘密鍵をサイドカーやログにコピーしてしまい、セキュリティ上のメリットを損なう。
- ローテーション直後に古い公開鍵を削除し、まだ有効なトークンを破損させる。
- 署名サービスのタイムアウトに対して無制限にリトライを行い、API サーバーのキューをパンクさせる。
- JWKS キャッシュ、クロックスキュー、およびレプリカの一貫性を検証せず、署名の成功のみをテストする。
- 監査境界を設けずに、署名サービス障害時の暗黙的な旧鍵発行を信頼できるフォールバックとして扱う。
フォローアップの質問と回答
署名サービスがダウンしている場合、API サーバーはローカルの古い秘密鍵を使い続けることができますか？
明示的な脅威モデル、監査、およびロールバック計画で許可されている場合に限られます。シークレットが API サーバーに戻らないよう、デフォルトでは新規発行を拒否すべきです。既存のトークンは、TTL が終了するまで古い公開鍵で検証を継続できます。
古い公開鍵を安全に削除できるのはいつですか？
最も長いトークン TTL、検証側の JWKS キャッシュ TTL、最大クロックスキュー、およびオフラインコンシューマーの保持期間から安全ウィンドウを計算し、古い kid の使用率がゼロであることを確認します。そのウィンドウが経過した後にのみ削除し、事前に復旧可能なバックアップを保持してください。
なぜ HTTP ではなく Unix ソケットを使用するのですか？
ローカルソケットはリスニングサーフェスを狭め、ファイルパーミッションとホストポリシーを使用してアクセスを制御します。これ単体でプロトコル認証、プロセス分離、または可用性が解決されるわけではないため、バージョニングされた API、監査、デッドライン、および障害訓練が引き続き必要です。