セキュリティ・プロファイルを理解する

Kubernetes ポッドセキュリティ標準は、以下の3つのプロファイルを定義している。

特権

デフォルトのポッドセキュリティ構成では、 privileged Kubernetes ポッドセキュリティプロファイルがグローバルに適用されます。このプロファイルは無制限であり、既知の特権の昇格を許可し、 restricted プロファイルによって設定されたポリシーに基づいて警告と監査イベントを生成します。

ベースライン

baseline プロファイルは、既知の特権昇格を防ぐ制限的なプロファイルである。 デフォルトの（最小限の）ポッド設定を許可する。

制限付き

restricted プロファイルは厳しく制限されており、現在のポッドハードニングのベストプラクティスに従っている。

ポッドセキュリティプロファイルの詳細については、 Kubernetes ドキュメントの プロファイルの詳細を参照してください。

ポッドセキュリティアドミッションには、潜在的な違反が検出された場合にコントロールプレーンが取る行動を定義する3つのモードがある。

適用

ポリシー違反があると、ポッドは拒否される。

監査

ポリシー違反は、監査ログに記録されるイベントへの監査注釈の追加を引き起こすが、それ以外は許可される。

warn

ポリシー違反はユーザーに警告を発するが、それ以外は許可される。

新しい機能に対応するためにセキュリティ標準やプロファイルの実装が変更されると、ロールの特定のバージョンを使用するようにポッドセキュリティアドミッションを設定できます。 対応バージョンは以下の通り。

• Kubernetes major.minor バージョン (例えば v1.25)
• latest

ポッドセキュリティ入学が自分に適していないとしたら？

ポッドセキュリティアドミッションは常に有効であるが、複数のアドミッションコントローラーのうちの1つになることができる。 サードパーティ Kubernetes のアドミッション・コントローラを設定して、ユースケースに適した他のセキュリティ・ポリシー・モデルを実装することができます。

privileged プロファイルを使用して、Pod Security Admission を強制、警告、監査するように構成すると、コントロールプレーンはすべての Pod の実行を許可します。 そして、他のアドミッション・コントローラがそれらを拒否するように設定することができる。

サードパーティのアドミッションコントローラは、以下のいずれかのアクションを取らない限り、インストールすることができます。

• 独自のポッドセキュリティポリシー（PSP）はインストールしない。
• ポリシーの一部を実施するためにPSPに頼ることはない。

ポッドセキュリティ入場ネームスペースラベルの設定

ネームスペースごとに、ポッドのセキュリティに使用するアドミッション・コントロール・モードを定義できます。 Kubernetes は、ネームスペースに使用する事前定義済みのポッドセキュリティ標準プロファイルを定義するために設定できるラベルのセットを定義します。 選択したラベルは、潜在的な違反が検出された場合にコントロール・プレーンが取るアクションを定義する。

デフォルトでは、 Red Hat OpenShift on IBM Cloud、以下のネームスペースに privileged 「Pod Security」ラベルが追加されます。 これらの名前空間は、 privileged プロファイルを使用して、 enforce、 audit、 warn にラベル付けされます。

• kube-system
• ibm-system
• ibm-operators
• calico-system
• tigera-operator
• calico-apiserver (バージョン 4.16 以降)

これらのネームスペースや openshift-* ネームスペースのラベルを削除したり変更したりしないでください。

名前空間をラベル付けして、いずれかまたはすべてのポッドセキュリティアドミッション modes に対してポッドセキュリティプロファイルを設定することができます。

たとえば、 warn または audit を使用することに加えて、 baseline プロファイルを使用して、 privileged プロファイルを強制するようにネームスペースにラベルを付けることができます。

このラベルによって、管理者とアプリケーション開発者は、ポッドを拒否せずに、 baseline プロファイルに対する警告と監査レコードだけを探して、アプリケーションをドライランすることができます。 その後、 baseline に変更する前に、ワークロードに必要な変更を加えることができます。

Pod Security Admission名前空間ラベルは、 pod-security.kubernetes.io/<MODE>: <LEVEL> と pod-security.kubernetes.io/<MODE>-version: <VERSION> の形式です。

• pod-security.kubernetes.io/enforce
• pod-security.kubernetes.io/enforce-version
• pod-security.kubernetes.io/audit
• pod-security.kubernetes.io/audit-version
• pod-security.kubernetes.io/warn
• pod-security.kubernetes.io/warn-version

ネームスペースにラベルを付けて、 privileged プロファイルを強制し、 baseline プロファイル違反に対して警告と監査イベントを生成するには、以下のラベルを使用します。

• pod-security.kubernetes.io/enforce: privileged
• pod-security.kubernetes.io/enforce-version: latest
• pod-security.kubernetes.io/audit: baseline
• pod-security.kubernetes.io/audit-version: latest
• pod-security.kubernetes.io/warn: baseline
• pod-security.kubernetes.io/warn-version: latest

デフォルトのPod Security Admissionプラグイン設定

Red Hat OpenShift on IBM Cloud デフォルトでは以下の PodSecurityConfiguration。

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

ポッドセキュリティアドミッションの設定

定義済みのポッド・セキュリティ・ラベルを使用して、ネームスペース・レベルでポッド・セキュリティの動作を構成できます。 設定の詳細については、 Red Hat OpenShift ドキュメントの「 Controlling pod security admission synchronization 」を参照してください。 クラスタのバージョンによって手順が異なるため、正しいバージョンの手順を表示していることを確認してください。

Red Hat OpenShift on IBM Cloud 用の apiserver ログ構成の詳細については、 Kubernetes API サーバー監査ログを 参照してください。

ポッドセキュリティ承認は、セキュリティプロファイルに違反したポッドに対して、強制、警告、監査イベントを生成する機能を提供します。 OpenShift 4.11 では、デフォルトの構成は特権プロファイルを強制し、同時に restricted プロファイルに基づいて警告と監査イベントを生成する。 この動作は、ネームスペースに定義済みのポッド・セキュリティ・ラベルを使用することで、ネームスペース・レベルで制御できます。 ポッドセキュリティプロファイルが適用されると、次の例のような警告が表示されることがあります。

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

この例では、サービスアカウント SecurityContextConstraint プロファイルの権限がある限り、ポッドは作成され、実行できます。 警告は、指定されたポッドセキュリティプロファイルの下でポッドを実行するには、 allowPrivilegeEscalation=false オプションの設定など、ポッドとコンテナの securityContext プロファイルへの変更が必要であるか、それらの機能を許可するポッドセキュリティプロファイルを使用する必要があることを示します。

Red Hat OpenShift また、与えられたネームスペースのサービスアカウント SCCパーミッションに基づいてネームスペースラベルを適用するコントローラも含まれている。 ポッドセキュリティアドミッションとSCCの両方が適用される。 主に SCC を使用し、ポッドセキュリティ許可同期コントローラを使用して、ネームスペースのポッドセキュリティラベルを調整できます。 または、ネームスペース内のすべてのサービス・ アカウント同等の（またはより特権のある）SCCを使用できるようにする、ネームスペース・ロール・バインディングを持つポッド・セキュリティ・プロファイルを主に使用することもできます。 これらのバインディングは、特定のSCCの下で実行されることを期待する Red Hat OpenShift コンポーネントに影響を与える可能性があるため、すべてのネームスペースのすべての許可されたユーザまたはすべてのサービスアカウント、グローバルに適用されるロールバインディングまたはクラスタロールバインディングを定義しないでください。

追加リソース

• ポッドセキュリティの入会を理解し、管理する。
• Red Hat OpenShift 4.11 におけるポッドセキュリティの入場。
• Kubernetes API サーバー監査ログ Red Hat OpenShift on IBM Cloud サービスで API サーバー監査ログを設定する方法について説明します。