KubernetesがPodSecurityPolicyを削除した理由と、その代替手段

2022年8月のKubernetes Blogの投稿で、プロジェクト側はPodSecurityPolicy（PSP）削除に関する歴史的な背景を提供しました。このアドミッションコントローラーは、v1.21リリースから始まった長い非推奨期間を経て、Kubernetes v1.25で正式に削除されました。記事では、PSPが安定版として認定されなかった理由と、後継者であるPod Security Admissionがどのようにこれらの課題に対処しているかを説明しています。

何が起きたのか

PodSecurityPolicyは、Kubernetes 1.0以前から存在していたRed Hat OpenShift Container Platformの最初のリリースにおけるSecurityContextConstraints（SCC）に由来しています。PSPは基本的に、アップストリームのKubernetes向けに設計されたSCCの簡略化バージョンでした。その作成は、正式なKubernetes Enhancements Proposal（KEP）プロセスよりも前に行われたため、初期の設計履歴を追跡することが困難でした。しかし、アーカイブによると、最終的な設計提案は、初期のコードマージが始まった後に作成されたことが示されています。

PSPの根幹部分は、2015年に始まる一連のプルリクエストを通じて追加されました。PSPが存在する以前、2015年7月10日にリリースされたKubernetes 1.0には、alpha品質のプラグインであるSecurityContextDenyを除き、セキュリティコンテキストを制限するメカニズムがありませんでした。OpenShiftのSCCに基づく最初のPSPオブジェクトは、9ヶ月間の議論を経て、2016年2月にアップストリームのKubernetesにマージされました。アドミッションコントローラーは2016年5月に続き、同年後半には異なるユーザーに対して異なるポリシーを適用できるようにするための認可メカニズムが追加されました。

意図されていたにもかかわらず、PSPは一度も安定版ステータスまで昇格しませんでした。欠陥のある認可モデル、デプロイの難しさ、および一貫性のないAPIに苦しんでいました。その結果、Kubernetesコミュニティはv1.25でこれを完全に削除することを決定しました。代わりに、名前空間レベルでPod Security Standardsを強制する新しいインツリープラグインであるPod Security Admissionが導入されました。

仕組み

PodSecurityPolicyは、ポッドのセキュリティフィールドに対する細粒度の権限を提供する特殊なアドミッションコントロールプラグインとして機能していました。これは、低レベルなLinuxセキュリティ判断をデプロイメントプロセスから切り離すことを目的としており、クラスター管理者が複雑なセキュリティプリミティブを理解せずにすべてのユーザーに安全なデフォルト設定を提供できるようにするためのものでした。システムは、root以外での実行や特権エスカレーションの制限などのルールを強制するために、変更（mutation）と検証（validation）に依存していました。

しかし、PSPはフェイルクローズ（fail-closed）方式で動作していました。ポリシーが存在しない場合、すべてのポッドが拒否されました。これにより、機能を有効にする前にすべてのワークロード用のポリシーを作成する必要があったため、デフォルトで有効にすることが困難でした。新しいポリシー下でどのポッドが失敗するかを特定するための監査モードがなく、頻繁な障害や不十分なテストカバレッジの原因となりました。さらに、ニッチなユースケースに対応するためにAPIが時間とともに一貫性を失い、他のアドミッションコントローラーとの組み合わせが難しくなりました。

代替機能であるPod Security Admissionは、Privileged、Baseline、Restrictedという3つの事前定義されたPod Security Standardsを強制することで、このモデルを簡素化します。Privilegedは無制限であり、Baselineはデフォルトの設定を許可し、Restrictedはセキュリティベストプラクティスを強制します。このアプローチにより、ほとんどのユーザーにとって深いセキュリティ知識が不要になり、採用と維持が容易な、安定した名前空間レベルの強制メカニズムが提供されます。

主要な詳細

• PodSecurityPolicyはv1.21で非推奨となった後、Kubernetes v1.25で削除されました。
• PSPはOpenShiftのSecurityContextConstraintsに由来し、2016年2月にKubernetesにマージされました。
• この機能は、欠陥のある認可モデルとデプロイの複雑さのために、安定版ステータスに到達できませんでした。
• PSPはフェイルクローズ方式で動作しており、有効にする前にすべてのワークロード用のポリシーが必要でした。
• Pod Security Admissionは、Privileged、Baseline、Restrictedの3つの標準を用いてPSPを置き換えます。
• 新しいアドミッションコントローラーはKubernetes v1.25で安定版であり、名前空間レベルで動作します。

なぜ重要なのか

ソフトウェアエンジニアやプラットフォームチームにとって、PSPからPod Security Admissionへの移行を理解することは、安全なクラスターを維持するために重要です。PSPは、デプロイメントの破綻を避けるために、Linuxセキュリティプリミティブに関する専門知識とポリシーの慎重な管理を必要としていました。その削除は、実装が容易で設定エラーが発生しにくい、よりシンプルで意見の統一されたセキュリティデフォルトへの移行を示唆しています。

新しいPod Security Standardsは、複雑なカスタムポリシーの管理に伴うオーバーヘッドなしに、ワークロードを保護するための明確な道筋を提供します。制限の3つの異なるレベルに焦点を当てることで、Kubernetesは開発者が基盤となるセキュリティメカニズムの深い知識を持たなくても、セキュリティベストプラクティスを採用しやすくします。この変更は、誤設定のリスクを減らし、Kubernetesクラスター全体のセキュリティ態勢を改善します。

できること

• クラスターをKubernetes v1.25以降にアップグレードして、安定版のPod Security Admissionコントローラーを使用してください。
• 既存のワークロードを確認し、BaselineまたはRestricted Pod Security Standardsに準拠していることを保証してください。
• 残っているPodSecurityPolicyオブジェクトを、望ましいセキュリティ標準を強制する名前空間レベルのラベルに置き換えてください。
• 以前のバージョンで利用可能な監査モードを使用して、新しい標準の下で失敗する可能性のあるポッドを特定してから、強制を開始してください。
• Pod Security Admissionの実装に関する実践的なチュートリアルについては、Kubernetesドキュメントを参照してください。
• 組み込みの標準でカバーされていない高度なユースケースについては、Pod Security Admissionを補完できるサードパーティ製アドミッションコントローラーを検討してください。