5.9. Pod セキュリティーアドミッションに準拠
Pod セキュリティーアドミッション は、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッション は Pod の動作を制限します。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。
Operator プロジェクトの実行に昇格された権限が必要ない場合は、restricted Pod セキュリティーレベルに設定された namespace でワークロードを実行できます。Operator プロジェクトの実行に昇格された権限が必要な場合は、次のセキュリティーコンテキスト設定を設定する必要があります。
- Operator の namespace に対して許可される Pod セキュリティーアドミッションレベル
- ワークロードのサービスアカウントに許可されるセキュリティーコンテキスト制約 (SCC)
詳細は、Pod セキュリティーアドミッションとその管理 を参照してください。
Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、OpenShift Container Platform の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、OpenShift Container Platform リリースから削除されます。
新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、OpenShift Container Platform 4.16 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、OpenShift Container Platform の新しいバージョンを対象とする Operator リリースを作成できます。
Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。
- Ansible ベースの Operator プロジェクトのベースイメージ
- Helm ベースの Operator プロジェクトのベースイメージ
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。
サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。
5.9.1. Pod セキュリティーアドミッションについて
OpenShift Container Platform には、Kubernetes Pod のセキュリティーアドミッション が含まれます。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。
グローバルに、privileged プロファイルが適用され、restricted プロファイルが警告と監査に使用されます。
Pod のセキュリティーアドミッション設定を namespace レベルで設定することもできます。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default、kube-public、kube-system、openshift、openshift-infra、openshift-node、および openshift.io/run-level ラベルが 0 または 1 に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
5.9.1.1. Pod のセキュリティーアドミッションモード
namespace に対して次の Pod セキュリティーアドミッションモードを設定できます。
| Mode | ラベル | 説明 |
|---|---|---|
|
|
| 設定されたプロファイルに準拠していない Pod の受け入れを拒否します。 |
|
|
| Pod が設定されたプロファイルに準拠していないと、監査イベントをログに記録します。 |
|
|
| Pod が設定されたプロファイルに準拠していないと警告を表示します。 |
5.9.1.2. Pod のセキュリティーアドミッションプロファイル
各 Pod セキュリティーアドミッションモードを次のプロファイルのいずれかに設定できます。
| プロファイル | 説明 |
|---|---|
|
| 最も制限の少ないポリシー。既知の権限昇格が可能になります。 |
|
| 最小限の制限ポリシー。既知の権限昇格を防止します。 |
|
| 最も制限的なポリシー。現在の 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 のセキュリティー許可 warn と audit ラベルは、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 セキュリティー適用の下ではイメージを実行できません。
手順
restrictedPod セキュリティーレベルに設定された 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) を編集する必要があります。
手順
次の例のように、Operator の CSV でセキュリティーコンテキスト設定を必要なパーミッションレベルに設定します。
ネットワーク管理者権限を持つ
<operator_name>.clusterserviceversion.yamlファイルの例... containers: - name: my-container securityContext: allowPrivilegeEscalation: false capabilities: add: - "NET_ADMIN" ...次の例のように、Operator のワークロードが必要なセキュリティーコンテキスト制約 (SCC) を使用できるようにするサービスアカウント権限を設定します。
<operator_name>.clusterserviceversion.yamlファイルの例... install: spec: clusterPermissions: - rules: - apiGroups: - security.openshift.io resourceNames: - privileged resources: - securitycontextconstraints verbs: - use serviceAccountName: default ...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.
