Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PodSecurityPolicyの安全な移行の道のり / On the safe migra...

uesyn
October 06, 2022

PodSecurityPolicyの安全な移行の道のり / On the safe migration of PodSecurityPolicy

uesyn

October 06, 2022
Tweet

More Decks by uesyn

Other Decks in Technology

Transcript

  1. ゼットラボ株式会社 / Z Lab Corporation ▶ 2015年に設立されたヤフー株式会社の 100%子会社 ▶ インフラ基盤技術の調査・研究開発

    ▶ ヤフー株式会社向けのマネージド Kubernetes サービスの開発 ▶ https://zlab.co.jp/ ▶ We are hiring!
  2. 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を試してみよう !」 をご参照ください。
  3. 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を試してみよう !」 をご参照ください。
  4. 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を試してみよう !」 をご参照ください。
  5. 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を試してみよう !」 をご参照ください。
  6. Yahoo! JAPANのPrivate CaaSについて ▶ 国内でも有数のPrivate CaaSの規模 ◦ クラスタ数: 1,207 ◦

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

    1,207 ◦ ノード数: 41,735 ◦ コンテナ数: 748,522 ▶ 会社として守らなければならないセキュリティ要件を全クラスタの Podへ適用している ◦ PodSecurityPolicy + Admission Webhook ◦ 全ての利用者はノードの特権を奪えるような Podを起動できない ▶ PSPは重要な役割を担っていた ◦ 移行先の検討は慎重にしなければならない 2022/9/13時点
  8. 移行の要件 ▶ セキュリティ要件の変更に柔軟であること ◦ クラスタ数は今後も増えていくと予想される ◦ 扱うサービスが増えれば扱うデータの種類も増え、セキュリティ要件も変わる可能性がある ▶ 実装がシンプルであること ◦

    問題があった場合でも原因調査・解決が容易となるため ◦ 静的にポリシーをチェックできれば良い ▪ リクエストのオブジェクト単体でチェックが完了するようなポリシーのみであったため ▶ コンピュートリソースの消費が少ないこと ◦ シンプルであることとのバランスは重要 ▶ 今まで作成できたPodは移行後も作成できること ▶ 移行の影響をチェックする仕組みを提供すること ◦ 静的なマニフェストチェックツールや既存クラスタの移行影響のチェックツールなど
  9. 移行先の選択肢 ▶ 選択肢としては大きく 3つ ◦ PodSecurity Adsmissionの利用 ◦ OSSの利用 ▪

    Keyverno, Gatekeeper/opaなどのOSS ◦ 要件に合うものを実装する
  10. 移行先の検討: PodSecurity Admissionの利用 ▶ 利用できるなら一番これを利用したい ◦ kube-apiserverに組み込まれているという大きなメリット ▪ 基本的に他の方法はAdmission Webhookとなり外部コンポーネントとなるため

    ◦ 公式にメンテナンスされるという安心感 ▶ しかし要件の一つであるカスタマイズ性が乏しい ... ◦ 利用していたポリシーが表現できない ▪ baselineプロファイルは一番自分達のポリシーに近いが一部変更する必要があった ▪ ポリシー変更分のみ毎回パッチを当てるという手もあるがやりたくない ▶ 上記のことが許容できず 不採用
  11. 移行先の検討: OSSの利用 ▶ kyverno, Gatekeeper, OpenPolicyAgentを検討 ◦ 全てカスタムポリシーを実装可能 ▶ kyverno

    ◦ 検証当時表現できないルールがあったため 不採用 ▶ Gatekeeper ◦ やりたいことに対してオーバースペック ▪ Informerやポリシーのテンプレートは不要 ▪ 静的にマニフェストをチェックできれば良い ◦ 不要な機能に対するリソース消費・メンテナンスコストなどが許容できず 不採用 ▶ OpenPolicyAgent ◦ シンプルなポリシーエンジンとして動いてくれる ▪ 必要な機能だけRegoで実装すれば良い ◦ 同じRegoのルールを使いまわすことで、静的マニフェストチェックツールの作成も可能 ▪ 例えばconftestなどを利用する OpenPolicyAgentを採用し実装を進めることに決定
  12. 移行スケジュール ▶ 段階的に移行を進めている ◦ 問題があっても切り戻しができるようにするため ▶ ポリシーに違反する場合、警告のみを返す期間を用意 ◦ 静的マニフェストチェックツールに加えて、より安全に移行を進めるために ◦

    kubectlなどの操作で警告が表示される v1.22 v1.23 v1.24 v1.25 ・マニフェストチェックツールの提供開始 ・パイロットユーザの検証 ・ポリシーをチェックするがリソースは拒否しない ・全クラスタで有効化開始 ・ポリシーをチェックするがリソースは拒否しない ・ポリシー違反するリソースを拒否 ・ここでPSPを無効化できる準備が完了 ・PSPの廃止 Kubernetes Version
  13. 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実装へ変更することを決断
  14. Goによる再実装 ▶ リソース消費量を大幅に減らすことができた ◦ おおよそ1/3になった ▶ レビュアーがハッピーになった ◦ チームメンバー的にRegoよりGoのレビューの方が取り組みやすかったため ▶

    conftestで配布したマニフェストチェックツールは現在も残ったまま ◦ RegoとGoそれぞれで実装したポリシーが二重管理となっている ◦ 今後こちらもGoで実装したルールを利用するように変更したい
  15. 免除条件の設定(2/3) ▶ Namespaceにより免除条件を実装するのは楽 ◦ Webhookで対象のNamespaceのリクエストの場合は常に Allowでレスポンス ◦ Validating/MutatingWebhookConfigurationsにより設定 ▶ Validating/MutatingWebhookConfigurationsの場合

    ◦ Kuberntes v1.21からNamespaceに kubernetes.io/metadata.name ラベルが追加された ◦ このラベルをセレクターに指定することで Admission Webhookの除外対象にできる
  16. 免除条件の設定(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であればポリシーの適用が免除される