fbpx

Kubernetes Pod Security Policy 非推奨化にあたり知っておくべきこと #aqua #コンテナ #セキュリティ #kubernetes #k8s #psp #pss

AquaSecurityKubernetes

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「Aqua Security」社の技術ブログで2021年2月23日に公開された「 Kubernetes Pod Security Policy Deprecation: All You Need to Know 」の日本語翻訳です。

Kubernetes Pod Security Policy 非推奨化にあたり知っておくべきこと

Kubernetes のセキュリティを向上させるためには、環境内でどのような Pod を作成してデプロイできるかを制御、制限する必要があります。このために、Kubernetes は Pod Security Policy(PSP)と呼ばれるベータ機能を提供していますが、間もなく非推奨となり、Pod Security Standards(PSS)と呼ばれる標準機能に置き換わる予定です。このブログでは、これが Kubernetes クラスタのセキュリティにとってどのような意味を持つのか、PSP からの移行方法、OPA ベースの Admission Controller が良い代替手段となる理由について説明します。

Pod Security Policy(PSP)を理解する

PSP 機能は Kubernetes の初期の頃から利用可能で、特定のクラスタ上で誤った設定の pod が作成されるのをブロックするように設計されています。PSP は、以下のような様々な Pod のパラメータをチェックする 16 のコントロールをサポートしています。

  • 特権コンテナの実行
  • ホストのネームスペースの使用
  • ホストネットワークとポートの使用


Example for pod security policy resource

PSP の主な欠点は、他のリソースタイプをサポートしていないことと、いくつかのコンテナランタイム固有のパラメータをカバーしておらず、コントロールのリストが限られていることです。PSP は 2021 年に非推奨となる予定で、同じニーズに対応するために、より良い代替手段があります。実際の非推奨日は、Azure などの PSP を使用しているベンダーが変更に備えることができるように、2021 年 2 月 1 日から 2021 年 5 月 3 日に延長されました。PSP は Kubernetes のバージョン 1.21 で正式に非推奨となり、バージョン 1.25 で削除される予定です。Kubernetes の非推奨ポリシーによると、旧バージョンでは機能の非推奨から 9 ヵ月後にサポートを受けられなくなります。

代替手段

では、どのような代替手段があるのでしょうか。Kubernetes の ValidateAdmissionWebhook と OPA(Open Policy Agent)を使用することで、PSP が提供するのと同じビルトインチェックを行うことができます。例えば、Service や CronJobs などのリソースにチェックを強制し、PSP がサポートしているチェックだけではなく、それらのリソースのあらゆる設定を評価できます。また Kubernetes のMutating Admission Controller を利用することで、リソースを変更したり、異なる方法でパッチを当てたりすることで、より多くのユースケースに対応できます。

Kubernetes の宣言的な構成管理機能により、IaC(Infrastructure as Code)が実現可能になります。リソースがどのように作成され、構成されるべきかを記述したマニフェストファイル(Yaml形式)を適用することで、リソースの望ましい状態を定義できます。このアプローチでは、異なるワークロードのライフサイクルポイント(コードリポジトリ、CI/CD パイプライン、デプロイ前チェック)にまたがって、OPA/Rego を使用して同じワークロード構成チェックを実行することを奨励します。

このコンセプトに後押しされて、Kubernetes リソースをさまざまな構成のベストプラクティスに照らし合わせて評価するためのツールが去年多く作られましたが、どのベストプラクティスに従うべきでしょうか。

公式の Pod Security Standards(PSS)

PSS は、Pod のセキュリティ関連のベストプラクティスへ対応するために、Kubernetes プロジェクトチームが定義した公式の基準です。これには「Baseline」と「Restricted」という2つのポリシーが含まれており、それぞれのポリシーには Pod のマニフェスト内のパラメータとその許容値のリストを持つコントロールが含まれています。これらのポリシーは、Rego/OPA チェックの検証をサポートするツールであれば、どのようなツールでも実施できます。

参考までに、以下の表は PSS と PSP のコントロールをマッピングしたもので、PSP からの移行計画を実施する場合に便利です。

PSS policy

PSS control

Mapping to PSP control

Baseline

Host Namespaces

ホストのネームスペースの使用

ホストネットワークとポートの使用

Privileged Containers

特権コンテナの使用

Capabilities

Linuxのケーパビリティ

HostPath Volumes

ホストのファイルシステムの使用

Host Ports

PSP サポート対象外

AppArmor (オプション)

コンテナの AppArmor プロファイルの使用

SELinux (オプション)

コンテナの SELinuxのコンテキスト

/proc Mount Type

コンテナの Proc マウントタイプ許可

Sysctls

コンテナの sysctl の使用

Restricted

Volume Types

Volumeタイプの使用

特定のボリュームドライバーの許可

read-only の root ファイルシステムの使用の必要性

Privilege Escalation

特権昇格の禁止

Running as Non-root

PSP サポート対象外

Non-root groups

Pod のボリュームを所有する FS グループを割り当てる

コンテナの UID 及び GID

Seccomp

コンテナの seccomp プロファイルの使用

一般的なアプリケーションは PSS に準拠しているか

Kubernetes のワークロード構成は目新しいものではありませんが、一般的なアプリケーションのセキュリティ意識は期待しているほど成熟していません。下の表では、一般的な Kubernetes Helm チャートが PSS Baseline と PSS Restricted にどのように準拠しているかを確認できます。

Helm chart

Pod controller

PSS - baseline

PSS - restricted

nginx-stable/Nginx-ingress:0.7.1

Deployment

以下のコントロールに失敗:
Capabilities
(NET_BIND_SERVICE added)

以下2つのコントロールに失敗:
Privilege Escalation,
Running as Non-root

stable/mysql:1.6.7

Deployment

Pass

以下のコントロールに失敗:
Running as Non-root

stable/kibana:3.2.8

Deployment

Pass

以下のコントロールに失敗:
Running as Non-root

stable/prometheus:11.12.1

Deployment

Pass

Pass

elastic/elasticsearch:7.10.2

StatefulSet

以下のコントロールに失敗:
Privileged Containers

Pass

stable/postgesql:8.6.4

StatefulSet

Pass

以下のコントロールに失敗:
Running as Non-root

stable/redis:10.5.7

StatefulSet

Pass

以下のコントロールに失敗:
Running as Non-root

stable/memcached:3.2.3

StatefulSet

Pass

以下のコントロールに失敗:
Running as Non-root

bitnami/cassandra:7.1.5

StatefulSet

Pass

以下のコントロールに失敗:
Running as Non-root

ワークロード構成のセキュリティに関するヒント

  1. 現在 PSP を利用している場合、代替手段を探すこと

    2. PSP 機能はベータ版であるにもかかわらず、一部の企業ではセキュリティポリシーの一部として使用しており、一部のベンダーはソリューションの中で PSP 機能に依存しています。効果のないセキュリティモデルにしたくないのであれば、できるだけ早く PSP ポリシーを OPA ベースの Admission Controller に置き換えることをお勧めします。

  2. ハードコードされたチェックツールを使用しないこと

    3. ハードコード化されたチェック機能を持つツールではなく、OPA/Rego をサポートするツールを使用することを推奨しています。OPA/Rego はベンダーのロックインを回避し、リソースマニフェスト内の任意のフィールドをチェックできる柔軟性とパワーを持ち、IaC から実行中のワークロードに至るまで、リソースのライフサイクルのすべての段階のチェックを一元的に管理できます。

  3. PSS Baseline から始めること

    4. PSS の Baseline ポリシーは、セキュリティと潜在的な摩擦の間にしっかりとしたバランスを提供し、最小限の例外リストを必要とするため、ワークロードセキュリティの良い出発点となります。

  4. Pod コントローラのチェックも忘れないこと
    ほとんどの標準では、単純化のために Pod を参照しています。Pod の状態を保持し、クラスタ上で ReplicaSet と Pod を生成する Pod コントローラ(Deployment、CronJob など)のチェックを実行することが重要です。一部のパラメーターでは、リソースマニフェストの階層が異なるため、注意の必要な場合があります。

    例えば、「HostIPC」パラメータは、Pod、Deployment、CrobJob 上で異なる階層を持っています。

    • Pod – spec.HostIPC
    • Deployment – spec.template.spec.HostIPC
    • CronJob – spec.jobTemplate.spec.template.spec.HostIPC
  5. コンテナイメージのチェックも忘れないこと
    PSS はほとんどの場合、環境内での特権昇格や攻撃者の横移動の可能性を防ぐ Pod の誤設定に焦点を当てています。しかし、ワークロード上の初期アクセスリスクは、通常脆弱性のあるアプリケーションから発生します。コンテナイメージを保護するには、次のようにします。

    • コンテナイメージのプレフィックスをチェックして、それが信頼できるレジストリでホストされているかどうかを確認します。
    • 有償版の製品は通常ワークロード構成チェックと統合されたイメージスキャンソリューションを提供しています。

コミュニティへの貢献

今までは、Pod Security Standards は Rego の実装では利用できませんでした。このため、PSP からの移行がより困難になり、コミュニティが OPA/Rego ソリューションを採用できなくなってしまいます。移行をスムーズに行うため、商用の Rego ライブラリをコミュニティへ公開することになりました。これは PSP と PSS の両方に加え、追加のベストプラクティスもカバーしており、最も包括的でメンテナンスの行き届いた Rego ライブラリです。ぜひ、ご利用の OPA/Rego ツールと一緒にお使いください。

New call-to-action
新規CTA