5.9. Pod セキュリティーアドミッションに準拠


Pod セキュリティーアドミッション は、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッション は Pod の動作を制限します。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。

Operator プロジェクトの実行に昇格された権限が必要ない場合は、restricted Pod セキュリティーレベルに設定された namespace でワークロードを実行できます。Operator プロジェクトの実行に昇格された権限が必要な場合は、次のセキュリティーコンテキスト設定を設定する必要があります。

  • Operator の namespace に対して許可される Pod セキュリティーアドミッションレベル
  • ワークロードのサービスアカウントに許可されるセキュリティーコンテキスト制約 (SCC)

詳細は、Pod セキュリティーアドミッションの理解と管理 を参照してください。

5.9.1. Pod セキュリティーアドミッションについて

OpenShift Container Platform には、Kubernetes Pod のセキュリティーアドミッション が含まれます。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。

グローバルに、privileged プロファイルが適用され、restricted プロファイルが警告と監査に使用されます。

Pod のセキュリティーアドミッション設定を namespace レベルで設定することもできます。

重要

デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。

デフォルトプロジェクトである defaultkube-publickube-systemopenshiftopenshift-infraopenshift-node、および openshift.io/run-level ラベルが 0 または 1 に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。

5.9.1.1. Pod のセキュリティーアドミッションモード

namespace に対して次の Pod セキュリティーアドミッションモードを設定できます。

表5.18 Pod のセキュリティーアドミッションモード
Modeラベル説明

enforce

pod-security.kubernetes.io/enforce

設定されたプロファイルに準拠していない Pod の受け入れを拒否します。

audit

pod-security.kubernetes.io/audit

Pod が設定されたプロファイルに準拠していないと、監査イベントをログに記録します。

warn

pod-security.kubernetes.io/warn

Pod が設定されたプロファイルに準拠していないと警告を表示します。

5.9.1.2. Pod のセキュリティーアドミッションプロファイル

各 Pod セキュリティーアドミッションモードを次のプロファイルのいずれかに設定できます。

表5.19 Pod のセキュリティーアドミッションプロファイル
プロファイル説明

privileged

最も制限の少ないポリシー。既知の権限昇格が可能になります。

baseline

最小限の制限ポリシー。既知の権限昇格を防止します。

restricted

最も制限的なポリシー。現在の Pod 強化のベストプラクティスに従います。

5.9.1.3. 特権付きの namespace

次のシステム namespace は、常に privileged Pod セキュリティーアドミッションプロファイルに設定されます。

  • default
  • kube-public
  • kube-system

これらの特権付き namespace の Pod セキュリティープロファイルを変更することはできません。

5.9.2. Pod セキュリティーアドミッション同期について

グローバル Pod セキュリティーアドミッションコントロール設定に加えて、コントローラーは、特定の namespace にあるサービスアカウントの SCC アクセス許可に従って、Pod セキュリティーアドミッションコントロールの warn および audit ラベルを namespace に適用します。

コントローラーは ServiceAccount オブジェクトのアクセス許可を確認して、各 namespace で Security Context Constraints を使用します。Security Context Constraints (SCC) は、フィールド値に基づいて Pod セキュリティープロファイルにマップされます。コントローラーはこれらの変換されたプロファイルを使用します。Pod のセキュリティー許可 warnaudit ラベルは、Pod の作成時に警告が表示されたり、監査イベントが記録されたりするのを防ぐために、namespace で最も特権のある Pod セキュリティープロファイルに設定されます。

namespace のラベル付けは、namespace ローカルサービスアカウントの権限を考慮して行われます。

Pod を直接適用すると、Pod を実行するユーザーの SCC 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。

5.9.2.1. Pod のセキュリティーアドミッション同期 namespace の除外

Pod のセキュリティーアドミッション同期は、システムで作成されたほとんどの namespace では永続的に無効になっています。ユーザーが作成した openshift-* 接頭辞が付いた namespace でも、同期は最初は無効になっていますが、後でそれらの同期を有効にすることができます。

重要

Pod セキュリティーアドミッションラベル (pod-security.kubernetes.io/<mode>) が、ラベル同期された namespace で自動的にラベル付けされた値から手動で変更された場合、そのラベルの同期は無効になります。

必要に応じて、次のいずれかの方法を使用して同期を再度有効にできます。

  • 変更された Pod セキュリティーアドミッションラベルを namespace から削除することによって
  • security.openshift.io/scc.podSecurityLabelSync ラベルを true に設定することによって

    このラベルを追加して同期を強制すると、変更された Pod セキュリティーアドミッションラベルはすべて上書きされます。

永続的に無効化された namespace

クラスターペイロードの一部として定義されている namespace では、Pod セキュリティーアドミッションの同期が完全に無効になっています。次の namespace は永続的に無効になります。

  • default
  • kube-node-lease
  • kube-system
  • kube-public
  • openshift
  • openshift- という接頭辞が付いたシステム作成の namespace すべて (openshift-operators を除く)
最初は無効になっている namespace

デフォルトでは、openshift- 接頭辞を持つすべての namespace では、最初は Pod セキュリティーアドミッション同期が無効になっています。ユーザーが作成した openshift-* namespace と openshift-operators namespace の同期を有効にできます。

注記

openshift-operators を除き、システムで作成された openshift-* namespace の同期を有効にすることはできません。

ユーザーが作成した openshift-* namespace に Operator がインストールされている場合、namespace にクラスターサービスバージョン (CSV) が作成された後、同期が自動的に有効になります。同期されたラベルは、namespace 内のサービスアカウントのアクセス許可から派生します。

5.9.3. Operator ワークロードが制限付き Pod セキュリティーレベルに設定された namespace で実行されるようにする

Operator プロジェクトがさまざまなデプロイメントおよび環境で確実に実行できるようにするには、restricted Pod セキュリティーレベルに設定された namespace で実行するように Operator のワークロードを設定します。

警告

runAsUser フィールドは空のままにしておく必要があります。イメージに特定のユーザーが必要な場合、制限付きセキュリティーコンテキスト制約 (SCC) および制限付き Pod セキュリティー適用の下ではイメージを実行できません。

手順

  • restricted Pod セキュリティーレベルに設定された namespace で実行されるように Operator ワークロードを設定するには、次の例のように Operator の namespace 定義を編集します。

    重要

    Operator の namespace 定義で seccomp プロファイルを設定することが推奨されます。ただし、seccomp プロファイルの設定は OpenShift Container Platform 4.10 ではサポートされていません。

    • OpenShift Container Platform 4.11 以降でのみ実行する必要がある Operator プロジェクトの場合は、次の例のように Operator の namespace 定義を編集します。

      config/manager/manager.yaml ファイル例

      ...
      spec:
       securityContext:
         seccompProfile:
           type: RuntimeDefault 1
         runAsNonRoot: true
       containers:
         - name: <operator_workload_container>
           securityContext:
             allowPrivilegeEscalation: false
             capabilities:
               drop:
                 - ALL
      ...

      1
      seccomp プロファイルタイプを RuntimeDefault に設定すると、SCC はデフォルトで namespace の Pod セキュリティープロファイルになります。
    • OpenShift Container Platform 4.10 でも実行する必要がある Operator プロジェクトの場合は、次の例のように Operator の namespace 定義を編集します。

      config/manager/manager.yaml ファイル例

      ...
      spec:
       securityContext: 1
         runAsNonRoot: true
       containers:
         - name: <operator_workload_container>
           securityContext:
             allowPrivilegeEscalation: false
             capabilities:
               drop:
                 - ALL
      ...

      1
      seccomp プロファイルタイプを未設定のままにすると、Operator プロジェクトを OpenShift Container Platform 4.10 で実行できるようになります。

5.9.4. エスカレーションされた権限を必要とする Operator ワークロードの Pod セキュリティーアドミッションの管理

Operator プロジェクトの実行に昇格されたアクセスパーミッションが必要な場合は、Operator のクラスターサービスバージョン (CSV) を編集する必要があります。

手順

  1. 次の例のように、Operator の CSV でセキュリティーコンテキスト設定を必要なパーミッションレベルに設定します。

    ネットワーク管理者権限を持つ <operator_name>.clusterserviceversion.yaml ファイルの例

    ...
    containers:
       - name: my-container
         securityContext:
           allowPrivilegeEscalation: false
           capabilities:
             add:
               - "NET_ADMIN"
    ...

  2. 次の例のように、Operator のワークロードが必要なセキュリティーコンテキスト制約 (SCC) を使用できるようにするサービスアカウント権限を設定します。

    <operator_name>.clusterserviceversion.yaml ファイルの例

    ...
      install:
        spec:
          clusterPermissions:
          - rules:
            - apiGroups:
              - security.openshift.io
              resourceNames:
              - privileged
              resources:
              - securitycontextconstraints
              verbs:
              - use
            serviceAccountName: default
    ...

  3. Operator の CSV 説明を編集して、Operator プロジェクトに次の例のような昇格された権限が必要な理由を説明します。

    <operator_name>.clusterserviceversion.yaml ファイルの例

    ...
    spec:
      apiservicedefinitions:{}
      ...
    description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.

5.9.5. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.