セキュリティー・プロファイルについて

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

特権

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

ベースライン

baseline プロファイルは、既知の特権エスカレーションを防止する制限付きプロファイルです。 デフォルト (最小指定) のポッド構成を許可します。

制限付き

restricted プロファイルは大きく制限されており、現在のポッド強化のベスト・プラクティスに従っています。

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

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

適用

ポリシー違反により、ポッドが拒否されます。

監査

ポリシー違反は、監査ログに記録されたイベントへの監査アノテーションの追加をトリガーしますが、それ以外の場合は許可されます。

warn

ポリシー違反は、ユーザーに表示される警告をトリガーしますが、それ以外の場合は許可されます。

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

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

ポッド・セキュリティー・アドミッションが私にとって適切な選択肢ではないとしたらどうでしょうか?

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

privileged プロファイルを使用してポッド・セキュリティー管理者が適用、警告、および監査を行うように構成した場合、コントロール・プレーンはすべてのポッドの実行を許可します。 その後、他のアドミッション・コントローラーがそれらを拒否するように構成できます。

以下のいずれのアクションも実行しない限り、サード・パーティーのアドミッション・コントローラーをインストールできます。

• 独自のポッド・セキュリティー・ポリシー (PSP) はインストールされません。
• ポリシーの一部を適用するために PSP に依存することはありません。

ポッド・セキュリティーのアドミッション名前空間ラベルの構成

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

デフォルトでは、 IBM Cloud Kubernetes Service は、 privileged ポッド・セキュリティー・ラベルを以下の名前空間に追加します。 これらの名前空間には、 privileged プロファイルを使用して、 enforce、 audit、および warn のラベルが付けられます。

• kube-system
• ibm-system
• ibm-operators
• calico-system (バージョン 1.29 以降)
• tigera-operator (バージョン 1.29 以降)
• calico-apiserver （バージョン ） 1.31

これらの名前空間のラベルを削除したり変更したりしないでください。

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

例えば、 baseline プロファイルを使用して、 warn または audit の使用に加えて、 privileged プロファイルを適用するために名前空間にラベルを付けることができます。

このラベルを使用すると、管理者およびアプリケーション開発者は、ポッドを拒否することなく、 baseline プロファイルに対する警告および監査レコードのみを検索することで、アプリケーションをドライランできます。 その後、強制モードを baseline に変更する前に、ワークロードに必要な変更を加えることができます。

ポッド・セキュリティー・アドミッションの名前空間ラベルの形式は、 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

デフォルトのポッド・セキュリティー・アドミッション・プラグイン構成

IBM Cloud Kubernetes Service は、デフォルトで以下の 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: []

ポッド・セキュリティー・アドミッション・プラグイン構成のカスタマイズ

クラスター全体のポッド・セキュリティー・アドミッション・プラグイン構成は、ポッド・セキュリティー・ラベルまたは免除がないすべての名前空間に対して enforce、 audit、および warn の動作を設定します。

Kubernetes 1.24 クラスターの場合、 apiVersion は pod-security.admission.config.k8s.io/v1beta でなければなりません。 1.25 以降の場合、 pod-security.admission.config.k8s.io/v1 が推奨されますが、 v1beta API バージョンは引き続き使用できます。

1. PodSecurityConfiguration リソースを含む YAML ファイルを作成します。 デフォルト構成を使用して開始できます。

   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: []
   

2. 使いたいカスタマイズをする。 構成の各セクションに関する以下の情報を確認してください。

   defaults

   構成の defaults セクションでは、ポッド・セキュリティー・ラベルがない名前空間のクラスター全体のデフォルトを定義します。 これらのフィールドは、対応するネームスペース・ラベルと同じ値を持つことができます。

   exemptions

   構成の exemptions セクションでは、特定の名前空間に関連付けられたポリシーのために禁止されているポッドを作成できます。 免除ディメンションには、以下のケースが含まれます。

   • ユーザー名: 免除された認証 (または偽名) ユーザー名を持つユーザーからの要求は無視されます。 ユーザー名は通常、IAM ユーザーまたはサービス・アカウントです。 例えば、 usernames: [ "IAM#user@example.com" ] などです。 admin kubeconfig クライアント証明書に関連付けられたユーザー名を免除することもできます。 admin kubeconfig 証明書を指定する場合、ユーザー名は現在のクライアント証明書の CN コンポーネントです。

     kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
     /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
     

     以下の例では、ユーザー名は IBMid-27000xxxxx-admin-2023-05-12 です。 新しい admin kubeconfig を取得した場合は、ユーザー名が異なる可能性があります。

     openssl x509 -in <client-certificate> -subject -noout`
     subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
     

   • RuntimeClassNames:除外されたランタイム・クラス名を指定するポッドとワークロード・リソースは無視されます。

   • 名前空間: 免除名前空間内のポッドおよびワークロード・リソースは無視されます。

3. カスタマイズした YAML ファイルを保存します。

4. ibmcloud ks cluster master pod-security set コマンドを実行します。

   ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
   

ibmcloud ks cluster master pod-security set コマンドを実行すると、構成ファイルを指定しない場合、ポッド・セキュリティー・アドミッションはデフォルト構成にリセットされます。