Pod Security Admissionの紹介 - enechain Tech Blog

ogp

はじめに

はじめまして、enechainのSREとして働いているsoma00333です。

enechainではプロダクトのデプロイ先としてGKEを採用しており、SREデスクではKubernetes Clusterの運用業務を行っています。また、enechainは「エネルギー市場を作る」というミッションを持っており、電力の取引を行なうマーケットのプロダクトを始めとして、データ可視化、リスクマネジメント、環境価値取引など、プロダクトの幅も増えてきています。 SREデスクとしても今後ますますセキュリティに力を入れていく予定です。

今回は、SREデスクのセキュリティに関する取り組みの一例として、Kubernetes v1.25でGAとなったPod Security Admissionを紹介します。

インフラ環境の紹介

enechainではシングルクラスタマルチテナントの構成で、GKEを使用したKubernetes Clusterを構築しています。

Development, Staging, Production, Test, CI/CD用等複数のClusterの運用を行っていますが、全て別々のGCP Projectで管理されています。また、CI/CD Pipelineに関してはGKE上のGitHub Actions self-hosted runnersやArgo CD, Cloud Buildを使用することでGitOpsを実現しています。

インフラ基盤の取り組みは、以前Google Cloudさんにインタビューしていただきました。

※ こちらのインタビュー記事をご覧ください

Pod Security Policyについて

Pod Security PolicyはKubernetesのポリシー制御の仕組みです。

しかし、Pod Security Policyはv1.21で非推奨となり、v1.25で削除されました。また、GKEではKubernetes v1.24が2024年1月8日にサポートが終了しているため、現在ポリシー制御を行うのであればOPA Gatekeeper・Kyverno等のサードパーティーツールや、v1.25でGAとなったPod Security Admissionの利用が推奨されています。

弊社ではCluster構築の初期段階からPod Security Policyを廃止し、Pod Security Admissionを採用しています。

Pod Security Standardとは

Kubernetesの公式ドキュメントでPod Security Standardsというガイドラインが提供されています。

このドキュメントでは、Podが他リソースへアクセスする際の権限セットを3つに分け、Podに目的に応じた権限のみを与えることでKubernetes Clusterのセキュリティを確保しよう、という内容が記載されています。

権限セット概要は以下のとおりです。

policy	説明	security level
Privileged	コンテナの設定項目に規定を設けないポリシー	low
Baseline	コンテナへの特権付与などリスクが明確な設定項目について最低限規定したポリシー	middle
Restricted	コンテナの実行ユーザーなど詳細な設定項目までを規定したベストプラクティスに該当するポリシー	high

Pod Security Admissionとは

Pod Security AdmissionはKubernetes v1.25でGAになったポリシー制御の仕組みです。

Pod Security Admissionでは3つのモードが提供されており、各モードに対して前述のPod Security Standardsのポリシーを指定するだけで、ポリシーを適用し権限を制限することができます。各モードに対してポリシーを指定しなかった場合、そのモードには暗黙的にPrivilegedが設定されます。また、Namespaceに対してポリシーを適用可能で、Dry-runも可能です。

モードとポリシー違反時の挙動は以下のとおりです。

モード	ポリシーに違反するPodのデプロイを検知した場合の挙動
enforce	Podのデプロイを拒否する
audit	Podはデプロイし、監査ログに出力する
warn	Podをデプロイし、コンソールに警告を出力する

Pod Security PolicyはRBACを使った認可によりポリシー適用を行うため、RBAC設定やPodのサービスアカウント設定等が複雑になるという課題がありました。しかし、Pod Security Admissionは以下のようにNamespaceに対してラベルを付与することでポリシーを設定することができます。

apiVersion: v1
kind: Namespace
metadata:
  name: sample-ns
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Pod Security Admissionの設定

enechainではDevelopment, Staging, Productionの3つのClusterに対して、以下の方針でポリシーの設計を行っています。

Productionは全てrestrictedで設定する
StagingとProductionの環境を合わせる
Development環境に関して、検証用のPodを素早く立てたい場合があるため、enforceをbaselineにすることを許容する
Development環境に関して、Podの起動は許可するが、restrictedのlevelでwarningを出す

そして、上記方針に従い、全Namespaceで以下のようにPod Security Admissionを設定しています。

environment	mode	level
development	enforce	baseline
development	audit	restricted
development	warn	restricted
staging	enforce	restricted
staging	audit	restricted
staging	warn	restricted
production	enforce	restricted
production	audit	restricted
production	warn	restricted

現在Development Clusterのenforceのみbaselineを許容しています。

各ApplicationのNamespaceだけでなく、GKE Clusterに導入したOSSや他全てのNamespaceに関しても上記ポリシーを適用しており、問題があるOSSに関してはパッチを当てることで解決しています。

今後の取り組み

ポリシー違反の際のログはモニタリングツールで確認することはできますが、アラートの仕組みがあるとさらに便利です。今後StagingやProductin環境でポリシー違反した際にSlackへアラートを上げる設定を行う予定です。

また、現在各Namespaceに対して個別でポリシーを設定していますが、設定が漏れたり誤った設定がなされる危険性があります。AdmissionConfigurationを使用してClusterに対してデフォルトポリシーを設定することも検討する予定です。

おわりに

今回はSREデスクのセキュリティに関する取り組みの一例としてPod Security Admissionについて紹介しました。

enechainのSREデスクはplatform engineering, site reliability, securityの3つのミッションを持っており、横軸エンジニアリングを推進できる非常に魅力的な環境です。 enechainではSREはもちろん、一緒に事業・組織を盛り上げてくれるエンジニア/デザイナー/マネジャーを募集しています。

興味を持っていただけたら、是非ご連絡ください。お待ちしております！

herp.careers herp.careers