Kubernetes Pod Security Standardsを理解する

Cloud Native Computing Foundation（CNCF）によると、2021年には560万人の開発者がコンテナのオーケストレーションにKubernetesを利用し、Kubernetesは「普及の壁を越えました」。CNCFの年次調査では、実に96%の組織がKubernetesの導入を検討中、またはすでに利用していることが記録されました。

しかし、Kubernetesの人気が高まるにつれて、ハッカーや悪意ある攻撃者にとっても魅力的な標的になっています。コンテナオーケストレーションの標準プラットフォームとしてKubernetesを採用する開発者が増える中、安全に利用することも重要です。

Kubernetes Pod Security Standardsは、Kubernetesのセキュリティを維持するための重要な手段です。非常に厳格なものから比較的自由度の高いものまで、段階的に適用できる3つのポリシーで構成されています。Kubernetes Pod Security Standardsとは何かを掘り下げ、Pod Security admission controllerが標準をどのように適用するかを確認し、各ポリシーのユースケースを紹介します。

Kubernetes Pod Security Standardsとは？

Kubernetes Pod Security Standardsは、Kubernetesクラスターにおけるコンテナのセキュリティと完全性を維持するためのポリシーとガイドラインです。コンテナ化されたワークロードを既知の権限昇格から保護し、Podのハードニングに関する最新のベストプラクティスに準拠させるため、制限の異なる3つのプロファイルを定義しています。

• Privileged: 制限のないポリシーを提供します。

• Baseline: 既知の権限昇格を防ぎながら、最小限の制約を設けます。

• Restricted: Podのハードニングに関する最新のベストプラクティスに従いますが、互換性が制限される場合があります。

これらの標準に準拠することで、Kubernetes環境内のコンテナ化されたアプリケーションが、業界標準のセキュリティ要件を満たしていることを確認できます。そのために、Kubernetesには組み込みのPod Security admission controllerが用意されており、Podの分離レベルがこれらのPod Security Standardsに適合しているかを確認できます。

以前のバージョンのKubernetesでは、この役割をPodSecurityPolicyが担っていました。しかし、Kubernetesはv1.21でこの機能を非推奨とし、v1.25で完全に削除しました。Kubernetes SIG Securityはブログ記事で、従来のアドミッションコントローラーには「深刻な使い勝手の問題」があったと説明しています。PodSecurityPolicyは分かりにくく、意図した範囲を超える権限を誤って付与しやすいうえ、特定の状況でどの権限が適用されるのか確認することも困難でした。こうした問題に対処するためにPodSecurityPolicyを改修するには、他の機能に影響を及ぼす可能性もある複雑なプロジェクトが必要だったため、非推奨となり、別の仕組みに置き換えられました。

Pod Security Standardsは、非推奨となったPodSecurityPolicyの標準レベルを基にしているため、PodSecurityPolicyを使用している従来のシステムも簡単に移行できます。組み込みのPod Security admission controllerは、クラスターまたは名前空間でこれらの標準を適用します。

Pod Security admission controllerの利用

Pod Security admission controllerを有効にしてWebhookをインストールしたら、名前空間でアドミッション制御のモードを設定できます。

• Enforce: ポリシー違反のあるPodを拒否します。

• Audit: ポリシー違反のあるPodを許可しますが、監査ログのイベントレコードに監査アノテーションを含めます。

• Warn: ポリシー違反のあるPodを許可しますが、ユーザーに警告します。

Pod Security admission controllerを設定するには、次の2つのラベルを指定します。

• Level: Privileged、Baseline、またはRestricted。

• Mode: Enforce、Audit、またはWarn。

同様に、任意の名前空間に複数のセキュリティチェックを設定できます。また、バージョンを指定し、そのKubernetesマイナーバージョンに付属するポリシーを基準にチェックすることもできます。

たとえば、「my-namespace」という名前空間がPod Security Standardsの最新のBaselineバージョンを満たしているか確認したい場合、次の警告を設定できます。

1kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/warn=baseline \
3   pod-security.kubernetes.io/warn-version=latest

また、「Baseline」レベルのセキュリティを適用しつつ、ログで通知を受けてセキュリティレベルを監査し、Restrictedレベルの標準を満たせるか確認したい場合は、次のように設定できます。

1 kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/enforce=baseline \
3   pod-security.kubernetes.io/enforce-version=latest
4   pod-security.kubernetes.io/audit=restricted \
5   pod-security.kubernetes.io/audit-version=latest

Privilegedセキュリティプロファイルの使用

Privilegedセキュリティプロファイルは既知の権限昇格を許容するため、重要なインフラストラクチャのワークロードを信頼できるユーザーのみが扱うような、限られたユースケースでのみ使用してください。

Kubernetes Pod Security StandardsのPrivilegedポリシープロファイルは、機密性の高いワークロードを管理するために必要な制限のない権限を提供し、重要なシステムで複雑なタスクを柔軟に実行できます。たとえば、機密性の高い金融情報を管理する組織を考えてみましょう。この場合、特権を持つ信頼できるユーザーが、組織のシステムレベルおよびインフラストラクチャレベルのワークロードを管理し、安全性を確保する必要があります。

このようなアクセスが必要になる場合もありますが、組織が制限のないアクセスを付与するのは、役割上それを必要とするユーザーに限るべきです。Privilegedプロファイルのような制約の緩い方法を使う場合は、権限の範囲を限定することが特に重要です。

また、Privilegedセキュリティプロファイルを使用する際は、Pod Security admission controllerでRestrictedレベルの警告モードと監査モードを有効にすることも重要です。これにより、各アクションの状態がユーザーに警告され、関連するすべてのイベントログエントリに監査アノテーションが付与されます。

最後に、Pod固有の対策以外のベストプラクティスも実施することが重要です。たとえば、広範な権限を付与することで生じる潜在的なリスクを軽減するため、多要素認証（MFA）を必須にすることが考えられます。

Baselineセキュリティプロファイルの使用

Baselineポリシーは、環境を複雑にすることなくセキュリティを確保したい、重要度の低いアプリケーションのオペレーターや開発者に最適です。Baselineポリシーを使えば、一般的なコンテナ化されたワークロードを管理しながら、既知の権限昇格から保護できます。

たとえば、ある組織が業務を支えるために、インフラストラクチャ上で重要度の低い複数のマイクロサービスを実行しているとします。Baselineポリシープロファイルを使えば、アプリケーションのオペレーターや開発者に大きな追加負担をかけずに、これらのワークロードの安全性を確保できます。この最小限の制約によって潜在的なリスクを抑え、コンテナイメージの脆弱性やその他の攻撃経路を通じて悪意ある攻撃者が昇格した権限を得ることを防ぎます。

この組織が、Kubernetesクラスターに保存されたデータへの読み取り専用アクセスを必要とするサードパーティベンダーのサービスを利用しているとします。Baseline Podセキュリティポリシーは、ベンダーに必要な範囲を超える特権アクセスを制限し、ベンダーやその他のユーザーがBaselineの要件を超えて権限を昇格しようとする不正な試みを拒否します。

Baselineセキュリティプロファイルは、APIやWebアプリケーションなど、一般的なワークロードを持つ組織にも柔軟性を提供します。追加のテストや分析を経て必要だと判断されない限り、追加の設定は不要です。

重要なのは、Baselineセキュリティプロファイルが幅広いワークロードを対象とするよう、汎用的に設計されていることです。そのため、特定のユースケースでは役に立たない制約が含まれる場合があります。rootアクセスを一律に許可するのは安全ではないため、Privilegedプロファイルをデフォルトにするのではなく、ユースケースに応じたアプリケーション固有の制御を設定する必要があるでしょう。

Restrictedセキュリティプロファイルの使用

Restrictedポリシープロファイルは、Podのハードニングに関する最新のベストプラクティスを適用するため、3つのプロファイルの中で最も安全です。

たとえば、ある組織が機密性の高い金融取引を処理するために、複数のコンテナ化されたワークロードをデプロイしているとします。一方で、最新のセキュリティ標準に従っていない、コンテナ化されていないアプリケーションを実行するレガシーシステムもあります。Restricted Podセキュリティポリシーを使えば、サンドボックス化、ユーザーアカウントの制限、ネットワーク権限の制御などのベストプラクティスに、すべてのコンテナを準拠させることができます。

Restrictedセキュリティプロファイルを使用すると、セキュリティ上の重要度が高いアプリケーションのオペレーターや開発者は、次のようなセキュリティ対策を実施できます。

• Pod内で実行されるすべてのコンテナが読み取り専用である。

• Linux capabilitiesを、コンテナの動作に必要なものだけに制限する。

• 環境変数を使って、各コンテナのホスト名を明示的に設定する。

• Podの作成時に、コンテナ内のプロセスごとに使用するCPUやメモリなどのリソースを指定する。

安全性の高いRestrictedポリシープロファイルを使うと、潜在的な攻撃対象領域をより明確に把握できます。特に、脆弱なワークロードを扱う組織に有効です。このポリシーは、Podのハードニングに関する最新のベストプラクティスを適用し、権限昇格などの悪意ある活動からの保護に役立ちます。

コア機能以外の不要なアプリケーション機能を削減したり、高度な脅威緩和機能を導入したりするなど、さまざまなポイントで多層防御を実施することで、セキュリティをさらに強化できます。

Pod Security Standardsの活用

Kubernetes Pod Security Standardsは、開発者がKubernetes環境内でコンテナ化されたアプリケーションの安全性を維持するのに役立ちます。3つのセキュリティプロファイル（Privileged、Baseline、Restricted）は、ユーザーのニーズに応じて制限の厳しさが異なります。Pod Security admission controllerは、選択したレベルに応じて適用、監査、警告を行うことで、クラスターまたは名前空間にこれらの標準を適用します。また、必要に応じてバージョンを指定することもできます。

組織はPod Security Standardsを活用して、業界標準のセキュリティ要件への準拠を確認しながら、潜在的な権限昇格やその他の悪意ある活動から保護できます。Pod Security admission controllerを通じてPod Security Standardsを適用すれば、Kubernetesクラスター内で実行されるあらゆるワークロードを保護しながら、開発プロセスを効率化できます。

KubernetesでPod Security Standardsを設定したら、Snyk Containerが開発プロセス全体を通じてコンテナの脆弱性を検出・修正し、コンテナを安全に保つためのインサイトや推奨事項を提供する方法をご覧ください。