Kubernetes Meetup Tokyo #53 (2022/10/6) Shinya Uemura, @uesyn PodSecurityPolicyの安全な移行の道のり

▶ ゼットラボ株式会社 ソフトウェアエンジニア ▶ 今回からKubernetes Meetup Tokyoの運営に参加しました Shinya Uemura / @uesyn

ゼットラボ株式会社 / Z Lab Corporation ▶ 2015年に設立されたヤフー株式会社の 100%子会社 ▶ インフラ基盤技術の調査・研究開発 ▶ ヤフー株式会社向けのマネージド Kubernetes サービスの開発 ▶ https://zlab.co.jp/ ▶ We are hiring!

アジェンダ ▶ PodSecurityPolicyとは？PodSecurityAdmissionとは？ ▶ Yahoo! JAPANのプライベートクラウドについて ▶ 移行計画と移行先の検討 ▶ 安全な移行のための取り組み ▶ 実装での気づき

PodSecurityPolicyとは？ PodSecurityAdmissionとは？

PodSecurityPolicy(PSP)が守っていたものは？ ▶ PodのCREATE/UPDATEリクエストは以下の流れ ▶ 組み込みの認可の仕組みである RBACはPodの作成の許可・拒否のみ ○ PodのSpecは考慮しない ▶ PSPはSpecの内容を見て許可・拒否を決定する 画像: https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ RBACはここ 詳しくはKubernetes Meetup Tokyo #44 の 「PodSecurityPolicyの廃止に備えて、 一足先にPodSecurity Admissionを試してみよう !」 をご参照ください。

PodSecurityPolicyの廃止について ▶ Kubernetes v1.25で廃止されました ▶ 経緯の詳細は以下のリンクをご参照ください ○ KEP-2579: Pod Security Admission Control - Motivation ■ https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2579-psp-replacement#motivation ○ PodSecurityPolicy Deprecation: Past, Present, and Future ■ https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/#why-is-podsecuritypolicy-going-away 詳しくはKubernetes Meetup Tokyo #44 の 「PodSecurityPolicyの廃止に備えて、 一足先にPodSecurity Admissionを試してみよう !」 をご参照ください。

PodSecurity Admissionとは？ ▶ PSPに代わるbuilt-inのPodのセキュリティのための Admission Control ▶ Kubernetes v1.23からbetaとなり、デフォルトで利用可能となった ▶ PodSecurityStandardsのプロファイル(privileged, baseline, restricted)を適用できる ▶ 3つのモードそれぞれに対してプロファイルを設定する ○ enforce: 違反したらPodの作成を拒否 ○ audit: 違反したらaudit logのアノテーションとして記録 (拒否はしない) ○ warn: 違反したらwarningとして表示(拒否はしない) 詳しくはKubernetes Meetup Tokyo #44 の 「PodSecurityPolicyの廃止に備えて、 一足先にPodSecurity Admissionを試してみよう !」 をご参照ください。

PodSecurityPolicyとPodSecurity Admission ▶ PodのSpecをチェックして、作成・更新の許可・拒否を制御する仕組み ▶ KubernetesのAdmission Controlとして実装されている ▶ PodSecurityPolicyは... ○ v1.25で廃止される ○ 定義されたルールから適用したいものを選択してポリシーを作成する ○ 複雑な条件を表現できたが、扱うのも難しかった ■ 間違った使い方をすると、 PSPが全く意味ない状態になる場合もありえる ▶ PodSecurity Admissionは... ○ v1.23からデフォルトで利用できる ○ PodSecurity StandardをPodに適用する ○ シンプルに利用できるがカスタムポリシーが設定できない 詳しくはKubernetes Meetup Tokyo #44 の 「PodSecurityPolicyの廃止に備えて、 一足先にPodSecurity Admissionを試してみよう !」 をご参照ください。

Yahoo! JAPANの プライベートクラウドについて

Yahoo! JAPANのPrivate CaaSについて ▶ 国内でも有数のPrivate CaaSの規模 ○ クラスタ数: 1,207 ○ ノード数: 41,735 ○ コンテナ数: 748,522 ▶ 会社として守らなければならないセキュリティ要件を全クラスタの Podへ適用している ○ PodSecurityPolicy + Admission Webhook ○ 全ての利用者はノードの特権を奪えるような Podを起動できない ▶ PSPは重要な役割を担っていた ○ 移行先の検討は慎重にしなければならない 2022/9/13時点

Yahoo! JAPANのPrivate CaaSについて これだけのクラスタでサービスやユーザの操作に 影響なくPSPの移行しなければならない ▶ 国内でも有数のPrivate CaaSの規模 ○ クラスタ数: 1,207 ○ ノード数: 41,735 ○ コンテナ数: 748,522 ▶ 会社として守らなければならないセキュリティ要件を全クラスタの Podへ適用している ○ PodSecurityPolicy + Admission Webhook ○ 全ての利用者はノードの特権を奪えるような Podを起動できない ▶ PSPは重要な役割を担っていた ○ 移行先の検討は慎重にしなければならない 2022/9/13時点

移行計画と移行先の検討

移行の要件 ▶ セキュリティ要件の変更に柔軟であること ○ クラスタ数は今後も増えていくと予想される ○ 扱うサービスが増えれば扱うデータの種類も増え、セキュリティ要件も変わる可能性がある ▶ 実装がシンプルであること ○ 問題があった場合でも原因調査・解決が容易となるため ○ 静的にポリシーをチェックできれば良い ■ リクエストのオブジェクト単体でチェックが完了するようなポリシーのみであったため ▶ コンピュートリソースの消費が少ないこと ○ シンプルであることとのバランスは重要 ▶ 今まで作成できたPodは移行後も作成できること ▶ 移行の影響をチェックする仕組みを提供すること ○ 静的なマニフェストチェックツールや既存クラスタの移行影響のチェックツールなど

移行先の選択肢 ▶ 選択肢としては大きく 3つ ○ PodSecurity Adsmissionの利用 ○ OSSの利用 ■ Keyverno, Gatekeeper/opaなどのOSS ○ 要件に合うものを実装する

移行先の検討: PodSecurity Admissionの利用 ▶ 利用できるなら一番これを利用したい ○ kube-apiserverに組み込まれているという大きなメリット ■ 基本的に他の方法はAdmission Webhookとなり外部コンポーネントとなるため ○ 公式にメンテナンスされるという安心感 ▶ しかし要件の一つであるカスタマイズ性が乏しい ... ○ 利用していたポリシーが表現できない ■ baselineプロファイルは一番自分達のポリシーに近いが一部変更する必要があった ■ ポリシー変更分のみ毎回パッチを当てるという手もあるがやりたくない ▶ 上記のことが許容できず 不採用

移行先の検討: OSSの利用 ▶ kyverno, Gatekeeper, OpenPolicyAgentを検討 ○ 全てカスタムポリシーを実装可能 ▶ kyverno ○ 検証当時表現できないルールがあったため 不採用 ▶ Gatekeeper ○ やりたいことに対してオーバースペック ■ Informerやポリシーのテンプレートは不要 ■ 静的にマニフェストをチェックできれば良い ○ 不要な機能に対するリソース消費・メンテナンスコストなどが許容できず 不採用 ▶ OpenPolicyAgent ○ シンプルなポリシーエンジンとして動いてくれる ■ 必要な機能だけRegoで実装すれば良い ○ 同じRegoのルールを使いまわすことで、静的マニフェストチェックツールの作成も可能 ■ 例えばconftestなどを利用する OpenPolicyAgentを採用し実装を進めることに決定

OpenPolicyAgentによるAdmission Webhookの実装 ▶ RegoでAdmission Webhookを実装する ○ 実装自体はとてもシンプル ▶ RegoではOR条件を表現するために 同じRule名を並べていけばよい ○ 右図はPrivilegedを制限する例 ○ ルールの追加はdenyを並べることで可能

安全な移行のための取り組み

移行に備えたマニフェストのチェック ▶ 細心の注意を払ってはいるが、 PSP移行後でも今まで通り Podが起動できるか不安 ▶ 移行前に移行後のポリシーでマニフェストをチェックするツールを提供 ○ 利用者側でその不安を払拭できるようにするため ▶ conftestにより実装 ○ OpenPolicyAgentで実装したRuleを併用 ▶ 提供方法 ○ ローカルで実行するための dockerイメージ ○ 社内CIで利用するための仕組み

移行スケジュール ▶ 段階的に移行を進めている ○ 問題があっても切り戻しができるようにするため ▶ ポリシーに違反する場合、警告のみを返す期間を用意 ○ 静的マニフェストチェックツールに加えて、より安全に移行を進めるために ○ kubectlなどの操作で警告が表示される v1.22 v1.23 v1.24 v1.25 ・マニフェストチェックツールの提供開始 ・パイロットユーザの検証 ・ポリシーをチェックするがリソースは拒否しない ・全クラスタで有効化開始 ・ポリシーをチェックするがリソースは拒否しない ・ポリシー違反するリソースを拒否 ・ここでPSPを無効化できる準備が完了 ・PSPの廃止 Kubernetes Version

実装での気づき

OpenPolicyAgentによる実装で感じた課題 ▶ Rego の学習コストが意外とつらかった ○ 自分だけなら良いがチームでのメンテナンスを考えると全員に知識を求めることになる ○ 型が欲しくなってくる ▶ Mutatingの実装が大変 ▶ リソース消費量が想定より多い ○ 100 req/sを処理可能なrequestをPodに設定しておきたかった ○ 必要なルールを設定した場合、 1 Podあたり 300m 程度の CPU request が必要であった ○ 冗長化のために 3 Podは起動したいため、1 クラスタ 300m x 3 = 900mのrequest ○ 会社全体として約1200クラスタ x 900m = 1080 core 確保する必要 ■ 想定より多く、可能であればこのリソース消費を抑えたい これらの理由からGo実装へ変更することを決断

Goによる再実装 ▶ リソース消費量を大幅に減らすことができた ○ おおよそ1/3になった ▶ レビュアーがハッピーになった ○ チームメンバー的にRegoよりGoのレビューの方が取り組みやすかったため ▶ conftestで配布したマニフェストチェックツールは現在も残ったまま ○ RegoとGoそれぞれで実装したポリシーが二重管理となっている ○ 今後こちらもGoで実装したルールを利用するように変更したい

Admission Webhookへ負荷をかける ▶ どの程度リクエストが処理できるか確認しておくことは当然必要 ▶ Webhook単体への負荷は一般的な Web Serverへの負荷試験と変わらない ▶ kube-apiserverの実際の通信を模して負荷をかけたい場合は dry-runを利用した ○ リソースを作成してしまうと etcdやNodeのリソースの制限を受けてしまったため

免除条件の設定(1/3) ▶ 全Podに対して同じポリシーの条件を適用するのは難しい ○ 監視やセキュリティなどのコンポーネントは強めの権限を必要とするものもある ○ 何かしらの免除条件が必要となる ▶ PodSecurity Admissionの場合は以下により免除条件が設定可能 ○ Namespace ■ 指定されたNamespace内のPodの操作は全て除外される ○ Username/Group ■ 指定されたUsername/GroupのPodの操作は全て除外される

免除条件の設定(2/3) ▶ Namespaceにより免除条件を実装するのは楽 ○ Webhookで対象のNamespaceのリクエストの場合は常に Allowでレスポンス ○ Validating/MutatingWebhookConfigurationsにより設定 ▶ Validating/MutatingWebhookConfigurationsの場合 ○ Kuberntes v1.21からNamespaceに kubernetes.io/metadata.name ラベルが追加された ○ このラベルをセレクターに指定することで Admission Webhookの除外対象にできる

免除条件の設定(3/3) ▶ Username/Groupの免除条件を実装は考慮する点がある ○ 免除されたユーザが作成した特権 Podを他のユーザがUpdateする場合は？ ○ ユーザでなくともコントローラなどが操作する可能性もある ■ finalizerなどを操作する必要があるかもしれない ■ そのため安全なフィールドの Updateであれば許容すべき ○ 安全なフィールドのUpdateとは? ■ これはKubernetesの実装に大きく依存してしまう ■ PodSecurity Admissionの実装は？ ● ハードコードされた安全なフィールドが定義されている ○ https://github.com/kubernetes/kubernetes/blob/v1.25.2/staging/src/k8s.io/pod-security-admi ssion/admission/admission.go#L628-L665 ● そのフィールドのUpdateであればポリシーの適用が免除される

PodSecurityPolicyリソースを残したまま Kubernetes v1.25へアップグレードすると？ ▶ リソースはetcdへ残ったままとなる ▶ 残っていても量が少なければ大きな問題にならないと思う (たぶん) ▶ v1.25からPSPリソースはアクセスできないため ○ 削除の必要があれば v1.24の間に実施する必要

まとめ ▶ PodSecurityPolicy(PSP)がKubernetes v1.25で廃止される ▶ PodSecurityAdmissionはPSPに代わる組み込みのセキュリティ機能 ○ 簡単に利用できるというメリットがあるものの柔軟性が少ない ▶ PSPの移行先はPodSecurityAdmissionだけでなくOSSや独自実装などがある ○ 要件に合わせて適切なものを選択できる ○ 我々は独自実装を選択した ▶ 実装における気づきを紹介