5.9. Pod セキュリティーアドミッションに準拠
Pod セキュリティーアドミッション は、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッション は Pod の動作を制限します。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。
Operator プロジェクトの実行に昇格された権限が必要ない場合は、restricted Pod セキュリティーレベルに設定された namespace でワークロードを実行できます。Operator プロジェクトの実行に昇格された権限が必要な場合は、次のセキュリティーコンテキスト設定を設定する必要があります。
- Operator の namespace に対して許可される Pod セキュリティーアドミッションレベル
- ワークロードのサービスアカウントに許可されるセキュリティーコンテキスト制約 (SCC)
詳細は、 Understanding and managing pod security admission を参照してください。
5.9.1. Pod セキュリティー標準とのセキュリティーコンテキスト制約の同期
OpenShift Container Platform には、Kubernetes Pod のセキュリティーアドミッション が含まれます。グローバルに、privileged プロファイルが適用され、restricted プロファイルが警告と監査に使用されます。
グローバル Pod セキュリティーアドミッションコントロールの設定に加えて、特定の namespace にあるサービスアカウントの SCC アクセス許可に従って、Pod セキュリティーアドミッションコントロールの warn ラベルと alert ラベルを namespace に適用するコントローラーが存在します。
クラスターペイロードの一部として定義されている namespace では、Pod セキュリティーアドミッションの同期が完全に無効になっています。必要に応じて、他の namespace で Pod セキュリティーアドミッション同期を有効にできます。
コントローラーは ServiceAccount オブジェクトのアクセス許可を確認して、各 namespace でセキュリティーコンテキストの制約を使用します。セキュリティーコンテキスト制約 (SCC) は、フィールド値に基づいて Pod セキュリティープロファイルにマップされます。コントローラーはこれらの変換されたプロファイルを使用します。Pod のセキュリティーアドミッション warn と aleart ラベルは、namespace 内で最も特権が高い Pod セキュリティープロファイルに設定され、Pod の作成時に警告と監査ログが発生しないようにします。
namespace のラベル付けは、namespace ローカルサービスアカウントの権限を考慮して行われます。
Pod を直接適用すると、Pod を実行するユーザーの SCC 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。
5.9.2. Operator ワークロードが制限付き Pod セキュリティーレベルに設定された名前空間で実行されるようにする
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.3. エスカレーションされた権限を必要とする 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.
