プロンプトとユースケース
プライベートイメージがすでにノード上に存在する場合でも、KubernetesはimagePullSecretsを検証すべきでしょうか？ポリシーをどのように選択し、安全にロールアウトしますか？このバックエンドのプロンプトでは、コンテナランタイムの動作、認証情報のライフサイクル、およびテナント分離がテストされます。IfNotPresent、共有される可能性のあるノード、短期間有効な認証情報をサポートするレジストリ、そしてセキュリティ変更がフリート全体の障害にならないようにする要件を前提とします。
面接官が評価するポイント
- 「バイトデータがこのノードに存在すること」と「このワークロードにそれを使用する権限があること」を区別できているか。
- kubeletが成功したプルと認証情報をどのように記録するか、およびプリロードされたイメージに個別のアプローチが必要な理由を説明できるか。
NeverVerify、NeverVerifyPreloadedImages、許可リスト、およびAlwaysVerifyをリスクとコストの観点から比較できるか。- ローテーション、ノードの再起動、キャッシュレコードの欠落、レジストリの障害、およびロールバックに対処できるか。
回答前に確認すべき質問
脅威モデルから始めます。ノードはマルチテナントか、イメージに機密コードが含まれているか、攻撃者がPodを作成できるかを確認します。イメージがkubeletによってプルされるのか、ノードの起動前にプリロードされるのか、また認証情報がPodのSecret、ノードのID、またはサービスアカウントトークンのどれから提供されるのかを尋ねます。ローテーションによって古いアクセスを即座に取り消す必要があるか、オフライン検証が許容されるか、レジストリがどれだけの再プル（repull）トラフィックを処理できるかを明確にします。最後に、目標が後方互換性なのか、より強力な分離なのか、機密性の高いネームスペースに対するより厳格なポリシーなのかを判断します。
30秒で答えるフレームワーク
「私はイメージキャッシュのヒットと認可を切り離して考えます。マルチテナントノードや機密性の高いイメージでは、バイトデータが存在するという理由だけでimagePullSecretsをバイパスすべきではありません。プルレコードを有効にし、まずはプリロードされたイメージの例外から開始して、ノードプールやネームスペースごとにAlwaysVerifyへと段階的に移行します。ガードレールとしては、起動成功率、再プル率、レジストリのレイテンシ、ローテーションの有効性、テナント間のアクセス拒否をモニタリングします。ロールアウトにはキャッシュレコードの移行、レジストリ障害時の動作設計、およびFeature Gateによるロールバックが必要です。」
ステップごとの詳細な回答
- 決定事項を分離する：キャッシュはバイトデータが存在するかどうかを答え、認証情報の検証はこのリクエストがそれらを使用してよいかを答えます。
IfNotPresentは認可ポリシーではありません。 - 成功した関連付けを記録する：kubeletは、イメージのプルに成功した認証情報を記録します。同一の認証情報はローカルでチェックできますが、不明な認証情報やローテーションされた認証情報はレジストリでのプルと認可が必要になります。
- プリロードされたイメージを処理する：kubeletの外部でロードされたイメージにはプルレコードがありません。
NeverVerifyPreloadedImagesは互換性を維持し、NeverVerifyAllowListedImagesは例外を絞り込み、AlwaysVerifyはすべてのイメージをチェックします。 - ローテーションを設計する：過去の成功した認証情報レコードは、新しい認証情報が有効であることを証明しません。ローテーション時には再プルまたは明示的な無効化を発生させ、レジストリのスロットリングと起動レイテンシを監視する必要があります。
- アップグレードリスクを管理する：初回有効化時、既存のイメージはプリロードされたものとして扱われる場合があります。信頼すべきでなくなったキャッシュエントリを削除し、kubeletの再起動やキャッシュファイルの移行を考慮に入れます。
- 段階的な適用とロールバック：ノードプール、ワークロードラベル、または低リスクのネームスペース単位で有効化し、拒否率やレジストリの負荷を監視します。迅速なロールバック経路として
NeverVerifyまたはFeature Gateを保持します。
質の高い模範解答
私は検証を行いますが、そのポリシーは脅威モデルに依存します。キャッシュヒットはノードにイメージのバイトデータが存在することのみを証明し、現在のPodがプライベートイメージを使用してよいかを証明するものではありません。マルチテナントノードにおいて検証をバイパスすると、異なる認証情報を持つワークロードがキャッシュされたイメージを不正に再利用できてしまいます。Kubernetesの設計では、kubeletがイメージとプルの成功した認証情報との関係を記録できるようになっています。同じ認証情報はローカルでチェック可能ですが、未知の認証情報やローテーション後の認証情報はレジストリへのアクセスが必要です。プリロードされたイメージにはこれらの記録がないため、互換性のためにNeverVerifyPreloadedImagesから開始し、機密性の高いノードプールをAlwaysVerifyへと移行させます。例外が必要な場合は、制御をグローバルに無効化するのではなく、明示的なプリロードイメージの許可リストを使用します。有効化する前に、信頼すべきでないキャッシュをクリーンアップし、kubeletの再起動、レコードの移行、レジストリのスロットリング、および認証情報のローテーションのリハーサルを実施します。カナリアリリース中は、Podの起動成功率、再プル率、レジストリのP95レイテンシ、認可拒否、およびクロステナントでの再利用の試行を比較します。レジストリの障害によって広範なコールドスタートの失敗が発生した場合は、アラートと監査レコードを保持したまま、Feature Gateまたはポリシーをロールバックします。これにより、セキュリティ境界、互換性、およびキャパシティリスクが単一のリリース判断に統合されます。
よくある間違い
- イメージダイジェストを、すべてのネームスペースにそのイメージの使用が認可されている証拠として扱ってしまうこと。
- プリロードされたイメージ、ノードの再起動、またはレジストリの障害について触れずに「
AlwaysVerifyを有効化する」とだけ答えること。 - 過去の成功レコードや再プルの動作を無視して、認証情報のローテーションを単なるSecretの更新として扱うこと。
- ノードプールごとのカナリア、レジストリのキャパシティ、ロールバックスイッチを用意せずに、フリート全体で一括してポリシーを切り替えること。
- プリロードの出所や許可リストを検証せずに、
NeverVerifyPreloadedImagesをセキュリティの保証と呼ぶこと。
フォローアップ質問と回答
なぜ同じ認証情報はレジストリへのリクエストなしで再チェックできるのですか？
プルの成功は、レジストリがそのイメージに対してその認証情報を受け入れたことを証明しているため、kubeletは既知の関係性をローカルで検証できます。認証情報の変更、レコードの欠落、または厳格なポリシーがある場合は、新しいプルまたはレジストリでのチェックが必要になります。
ノードの再起動後にキャッシュレコードが消失した場合はどうなりますか？
レコードをkubeletのディレクトリに永続化し、バージョンごとに移行します。レコードが読み取れない場合は、キャッシュされたイメージを誰もが利用できるように暗黙的に許可するのではなく、より厳格な経路をとって再プルを実行します。
レジストリが一時的に利用できない場合、キャッシュされたイメージを許可すべきですか？
低リスクな環境であれば、明確に定義され、可視化された期間限定の縮退動作を認める場合があります。機密性の高いワークロードでは認可をバイパスすべきではありません。インシデントが恒久的な過剰権限状態にならないよう、オフラインで許可されたリクエストを記録します。
ローテーションが実際に機能していることをどのように証明しますか？
古いSecret、新しいSecret、Secretなし、および異なるネームスペースのIDを使用して、同じプライベートイメージを起動します。kubeletイベント、レジストリへのアクセス、キャッシュレコード、およびPodの結果を確認します。古い認証情報が失敗し、新しい認証情報が成功し、スロットリング発生時に計画通りのロールバック動作がトリガーされることを検証します。