Kubernetes v1.33、Pod間でのプライベートイメージ再利用を修正

2025年5月のKubernetes Blogの投稿で、メンテナーのBen Petersen氏とStanislav Láznička氏は、Kubernetes v1.33における重要なセキュリティ調整について説明しました。このアップデートは、同じノード上の他のPodによって取得されたプライベートコンテナイメージに、適切な認可なしにPodが誤ってアクセスできてしまうという、10年来の問題に対処しています。

何が起きたのか

過去10年以上にわたり、KubernetesユーザーはimagePullPolicy: IfNotPresent設定に関連した、微妙ながら重大なセキュリティギャップに直面してきました。このポリシーは、毎回レジストリからイメージを取得する代わりに、ローカルキャッシュが存在すればそれを使用することでパフォーマンスを最適化するために設計されています。しかし、この最適化は以前、同じノードにスケジュールされた異なるPod間の認証境界を無視していました。

核心的な問題は、Pod AがimagePullSecretを通じて特定の資格情報で認可され、プライベートイメージをノード上に取得した場合に生じました。もし異なる名前空間に属し、そのプライベートリポジトリに対する有効な資格情報を一切持たないPod Bが、その後同じノードにIfNotPresentポリシーでスケジュールされると、Kubeletはキャッシュされたイメージの使用を許可していました。Pod Bはそのイメージを取得する認可を受けていなかったにもかかわらず、バイナリレイヤーがすでにディスク上に存在するという理由だけでアクセス権を得ていました。この挙動は最小権限の原則に違反しており、クラスター内で潜在的なサプライチェーンセキュリティリスクを生み出していました。

Kubernetes v1.33のリリースに伴い、SIG AuthおよびSIG Nodeは、イメージがキャッシュされている場合でも資格情報の検証を強制するための修正を導入しました。新しい挙動により、Podがローカルに存在するプライベートイメージを使用できるのは、初回取得時に使用されたものと一致する資格情報を提供する場合のみとなります。この変更により、認可されたワークロードに対するローカルキャッシュのパフォーマンス上の利点を維持しつつ、抜け穴を塞ぎます。

仕組み

このソリューションは、各ノード上のKubeletによって維持される永続的なファイルベースのキャッシュに依存しています。Podが現在ノード上に存在しないイメージを要求すると、Kubeletは取得意図を記録します。次に、参照されているKubernetes Secretから資格情報を抽出し、プライベートレジストリからの取得を実行します。成功すると、Kubeletはこのイベントの記録（使用された資格情報のハッシュ値とソースSecret識別子を含む）を保存します。

後続のPodが同じイメージを要求すると、Kubeletはローカルキャッシュを確認します。キャッシュされたイメージを無条件に提供するのではなく、新しいPodが提供した資格情報を保存されたレコードと比較します。資格情報のハッシュ値またはソースSecretが以前の正常な取得と一致する場合、Podはデータを再ダウンロードせずにキャッシュされたイメージへのアクセス権が付与されます。一致がない場合、Kubeletは新しい資格情報を使用してリモートレジストリからのイメージ取得を試み、標準的な認可フローを開始します。このメカニズムにより、有効で一致する資格情報を持つPodのみがキャッシュされたプライベートイメージを再利用できるようになります。

主要な詳細

• この修正は、Kubernetesに10年以上存在していたセキュリティ上の注意書きであるissue 18787に対応しています。
• この機能はKubernetes v1.33でアルファリリースとして利用可能です。
• 新しい挙動を有効にするには、ユーザーはKubeletでKubeletEnsureSecretPulledImagesフィーチャーゲートを有効にする必要があります。
• 同じ資格情報またはソースSecretを使用するPodは再認証する必要がなく、パフォーマンスが維持されます。
• imagePullPolicy: Neverポリシーも、ノード上に既に存在するプライベートイメージに対して資格情報の検証を必要とするようになりました。
• 今後の計画には、Projected service account tokensとの統合や、資格情報の有効期限サポートの追加が含まれています。

なぜ重要なのか

ソフトウェアエンジニアやプラットフォームチームにとって、この変更は大幅な運用変更に頼ることなくクラスターの分離性を強化します。以前は、多くの組織がすべてのPodがレジストリに対して認証チェックを行うことを保証するため、imagePullPolicy: Alwaysを回避策として強制していました。これは安全ですが、すべてのPodの起動、スケールアップ、または再起動においてイメージレジストリをクリティカルパスに置き、遅延を増加させ外部サービスへの依存を高めていました。新しい検証メカニズムにより、チームは厳格なセキュリティ制御を維持しながら、レジストリの負荷を減らし起動時間を改善するためにIfNotPresentを安全に使用できるようになります。

このアップデートはまた、マルチテナントクラスター管理を簡素化します。複数のチームがノードを共有する環境では、あるチームが別のチームのプライベートイメージに誤ってアクセスするリスクが、Kubeletレベルで軽減されました。プラットフォームエンジニアは、不正なイメージ使用を防ぐためにネットワークポリシーやアドミッションコントローラーだけに頼るのではなく、アクセスポリシーを強制するためにインフラストラクチャに信頼を置けるようになります。この変化は、セキュリティと分離に関するユーザーの期待により近い挙動をKubernetesにもたらします。

対応可能なこと

• テストクラスターをKubernetes v1.33にアップグレードし、新機能を評価してください。
• Kubelet設定でKubeletEnsureSecretPulledImagesフィーチャーゲートを有効にしてください。
• 現在のimagePullPolicy設定を見直し、適切であればパフォーマンス向上のためにAlwaysからIfNotPresentへの変更を検討してください。
• プライベートイメージにアクセスするすべてのPodが、必要なimagePullSecretsを正しく参照していることを確認してください。
• 初期展開中にKubeletログを監視し、認証失敗を検出して設定ミスのPodを特定してください。
• この機能に関する詳細な技術仕様や将来のロードマップ項目については、KEP-2535をお読みください。