認証および認可
Red Hat OpenShift Service on AWS クラスターのセキュリティー保護
概要
第1章 サービスアカウントの AWS IAM ロールを引き受ける
AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターには、ユーザー定義のプロジェクトで実行する Pod で使用するための Pod ID Webhook が含まれています。
Pod ID Webhook を使用して、サービスアカウントが独自の Pod で AWS Identity and Access Management (IAM) ロールを自動的に引き受けるようにすることができます。想定された IAM ロールに必要な AWS アクセス許可がある場合、Pod は一時的な STS 認証情報を使用して AWS SDK 操作を実行できます。
1.1. ユーザー定義プロジェクトでの Pod ID Webhook ワークフローについて
AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターをインストールすると、Pod ID Webhook リソースがデフォルトで含まれます。
Pod ID Webhook を使用して、ユーザー定義プロジェクトのサービスアカウントが、同じプロジェクトの Pod で AWS Identity and Access Management (IAM) ロールを引き受けることができます。IAM ロールを引き受けると、Pod 内のサービスアカウントが使用する一時的な STS 認証情報が提供されます。引き受けたロールに必要な AWS 権限がある場合、サービスアカウントは Pod で AWS SDK 操作を実行できます。
Pod の Pod ID Webhook を有効にするには、プロジェクトで eks.amazonaws.com/role-arn アノテーションを使用してサービスアカウントを作成する必要があります。アノテーションは、サービスアカウントが引き受ける AWS IAM ロールの Amazon Resource Name (ARN) を参照する必要があります。また、Pod 仕様でサービスアカウントを参照し、サービスアカウントと同じプロジェクトに Pod をデプロイする必要があります。
ユーザー定義プロジェクトでの Pod ID Webhook ワークフロー
次の図は、ユーザー定義プロジェクトでの Pod ID Webhook ワークフローを示しています。
図1.1 ユーザー定義プロジェクトでの Pod ID Webhook ワークフロー

ワークフローには次の段階があります。
-
ユーザー定義のプロジェクト内で、ユーザーは
eks.amazonaws.com/role-arnアノテーションを含むサービスアカウントを作成します。アノテーションは、サービスアカウントが引き受ける AWS IAM ロールの ARN を指します。 アノテーション付きのサービスアカウントを参照する設定を使用して Pod が同じプロジェクトにデプロイされると、Pod ID Webhook により Pod が変更になります。ミューテーションは、
PodまたはDeploymentリソース設定で指定する必要なく、次のコンポーネントを Pod に挿入します。-
AWS SDK オペレーションを実行するために必要なアクセス権を持つ IAM ロールの ARN を含む
$AWS_ARN_ROLE環境変数。 -
サービスアカウントの OpenID Connect (OIDC) トークンへの Pod 内のフルパスを含む
$AWS_WEB_IDENTITY_TOKEN_FILE環境変数。フルパスは/var/run/secrets/eks.amazonaws.com/serviceaccount/tokenです。 -
マウントポイント
/var/run/secrets/eks.amazonaws.com/serviceaccountにマウントされたaws-iam-tokenボリューム。tokenという名前の OIDC トークンファイルがボリュームに含まれています。
-
AWS SDK オペレーションを実行するために必要なアクセス権を持つ IAM ロールの ARN を含む
OIDC トークンは、Pod から OIDC プロバイダーに渡されます。次の要件が満たされている場合は、プロバイダーがサービスアカウント ID を認証します。
- ID 署名は有効であり、秘密鍵によって署名されています。
sts.amazonaws.comオーディエンスは OIDC トークンにリストされており、OIDC プロバイダーで設定されたオーディエンスと一致します。注記Pod ID Webhook は、デフォルトで
sts.amazonaws.comオーディエンスを OIDC トークンに適用します。STS クラスターを使用する Red Hat OpenShift Service on AWS では、インストール中に OIDC プロバイダーが作成され、デフォルトでサービスアカウント発行者として設定されます。
sts.amazonaws.comオーディエンスは、デフォルトで OIDC プロバイダーに設定されています。- OIDC トークンの有効期限が切れていません。
- トークンの発行者の値には、OIDC プロバイダーの URL が含まれています。
- プロジェクトとサービスアカウントが、引き受ける IAM ロールの信頼ポリシーのスコープ内にある場合は、認可が成功します。
- 認証と認可が成功すると、セッショントークンの形式の一時的な AWS STS 認証情報が Pod に渡され、サービスアカウントで使用できるようになります。認証情報を使用することで、IAM ロールで有効になっている AWS アクセス許可がサービスアカウントに一時的に付与されます。
- Pod で AWS SDK オペレーションを実行すると、サービスアカウントは一時的な STS 認証情報を AWS API に提供して、その ID を確認します。
1.2. 独自の Pod で AWS IAM ロールを引き受ける
このセクションの手順に従って、ユーザー定義のプロジェクトにデプロイされた Pod でサービスアカウントが AWS Identity and Access Management (IAM) ロールを引き受けられるようにします。
AWS IAM ロール、サービスアカウント、AWS SDK を含むコンテナーイメージ、イメージを使用してデプロイされた Pod など、必要なリソースを作成できます。この例では、AWS Boto3 SDK for Python が使用されています。また、Pod ID Webhook が AWS 環境変数、ボリュームマウント、およびトークンボリュームを Pod に変更することを確認することもできます。さらに、サービスアカウントが Pod で AWS IAM ロールを引き受け、AWS SDK オペレーションを正常に実行できることを確認できます。
1.2.1. サービスアカウントの AWS IAM ロールの設定
Red Hat OpenShift Service on AWS クラスターのサービスアカウントが引き受ける AWS Identity and Access Management (IAM) ロールを作成します。サービスアカウントが Pod で AWS SDK オペレーションを実行するために必要なアクセス許可をアタッチします。
前提条件
- AWS アカウントに IAM ロールをインストールして設定するために必要なアクセス許可がある。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
STS クラスターを使用する Red Hat OpenShift Service on AWS でサービスアカウント発行者として設定されている OpenID Connect (OIDC) プロバイダーの Amazon Resource Name (ARN) がある。
注記STS クラスターを使用する Red Hat OpenShift Service on AWS では、インストール中に OIDC プロバイダーが作成され、デフォルトでサービスアカウント発行者として設定されます。OIDC プロバイダーの ARN がわからない場合は、クラスター管理者に問い合わせてください。
-
AWS CLI (
aws) をインストールしている。
手順
次の JSON 設定を使用して、
trust-policy.jsonという名前のファイルを作成します。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "<oidc_provider_arn>" 1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<oidc_provider_name>:sub": "system:serviceaccount:<project_name>:<service_account_name>" 2 } } } ] }- 1
<oidc_provider_arn>を OIDC プロバイダーの ARN に置き換えます (例:arn:aws:iam::<aws_account_id>:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44npxu4g58so46aeohduomfres)。- 2
- 指定されたプロジェクトとサービスアカウントにロールを制限します。
<oidc_provider_name>を OIDC プロバイダーの名前に置き換えます (例:rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44npxu4g58so46aeohduomfres)。<project_name>:<service_account_name>を実際のプロジェクト名とサービスアカウント名に置き換えます (例:my-project:test-service-account)。注記または、
"<oidc_provider_name>:sub": "system:serviceaccount:<project_name>:*"を使用して、指定したプロジェクト内の任意のサービスアカウントにロールを制限できます。*ワイルドカードを指定する場合は、前の行でStringEqualsをStringLikeに置き換える必要があります。
trust-policy.jsonファイルで定義されている信頼ポリシーを使用する AWS IAM ロールを作成します。$ aws iam create-role \ --role-name <aws_iam_role_name> \ 1 --assume-role-policy-document file://trust-policy.json 2出力例:
ROLE arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name> 2022-09-28T12:03:17+00:00 / AQWMS3TB4Z2N3SH7675JK <aws_iam_role_name> ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:<project_name>:<service_account_name> PRINCIPAL <oidc_provider_arn>
出力でロールの ARN を保持します。ロール ARN の形式は
arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>です。サービスアカウントが Pod で AWS SDK 操作を実行するときに必要なマネージド AWS アクセス許可をアタッチします。
$ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \ 1 --role-name <aws_iam_role_name> 2- オプション: カスタム属性または権限境界をロールに追加します。詳細は、AWS ドキュメントの AWS サービスにアクセス許可を委任するロールの作成 を参照してください。
1.2.2. プロジェクトでサービスアカウントを作成する
ユーザー定義プロジェクトにサービスアカウントを追加します。サービスアカウントに引き受けさせる AWS Identity and Access Management (IAM) ロールの Amazon Resource Name (ARN) を参照する eks.amazonaws.com/role-arn アノテーションをサービスアカウント設定に含めます。
前提条件
- サービスアカウントの AWS IAM ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) クラスターを使用して Red Hat OpenShift Service on AWS にアクセスできます。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc) がインストールされている。
手順
Red Hat OpenShift Service on AWS クラスターで、プロジェクトを作成します。
$ oc new-project <project_name> 1- 1
<project-name>は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。
注記プロジェクトが作成されると、自動的にプロジェクトに切り替わります。
次のサービスアカウント設定で、
test-service-account.yamlという名前のファイルを作成します。apiVersion: v1 kind: ServiceAccount metadata: name: <service_account_name> 1 namespace: <project_name> 2 annotations: eks.amazonaws.com/role-arn: "<aws_iam_role_arn>" 3
- 1
<service_account_name>をサービスアカウントの名前に置き換えます。この名前は、AWS IAM ロールの設定で指定したサービスアカウント名と一致させる必要があります。- 2
<project-name>は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。- 3
- サービスアカウントが Pod 内で使用するために想定する AWS IAM ロールの ARN を指定します。
<aws_iam_role_arn>を、サービスアカウント用に作成した AWS IAM ロールの ARN に置き換えます。ロール ARN の形式はarn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>です。
プロジェクトにサービスアカウントを作成します。
$ oc create -f test-service-account.yaml
出力例:
serviceaccount/<service_account_name> created
サービスアカウントの詳細を確認します。
$ oc describe serviceaccount <service_account_name> 1- 1
<service_account_name>をサービスアカウントの名前に置き換えます。
出力例:
Name: <service_account_name> 1 Namespace: <project_name> 2 Labels: <none> Annotations: eks.amazonaws.com/role-arn: <aws_iam_role_arn> 3 Image pull secrets: <service_account_name>-dockercfg-rnjkq Mountable secrets: <service_account_name>-dockercfg-rnjkq Tokens: <service_account_name>-token-4gbjp Events: <none>
1.2.3. サンプル AWS SDK コンテナーイメージの作成
この手順のステップでは、AWS SDK を含むコンテナーイメージを作成する方法の例を示します。
例の手順では、Podman を使用してコンテナーイメージを作成し、Quay.io を使用してイメージをホストします。Quay.io の詳細は、Quay.io の使用を開始する を参照してください。コンテナーイメージを使用して、AWS SDK オペレーションを実行できる Pod をデプロイできます。
この手順例では、AWS Boto3 SDK for Python がコンテナーイメージにインストールされます。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
前提条件
- インストールホストに Podman をインストールしている。
- Quay.io ユーザーアカウントを持っている。
手順
次の設定を
Containerfileという名前のファイルに追加します。FROM ubi9/ubi 1 RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0 2
ファイルを含むディレクトリーから、
awsboto3sdkという名前のコンテナーイメージをビルドします。$ podman build -t awsboto3sdk .
Quay.io にログインします。
$ podman login quay.io
Quay.io へのアップロードの準備として、イメージにタグを付けます。
$ podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest 1- 1
<quay_username>を Quay.io ユーザー名に置き換えます。
タグ付けされたコンテナーイメージを Quay.io にプッシュします。
$ podman push quay.io/<quay_username>/awsboto3sdk:latest 1- 1
<quay_username>を Quay.io ユーザー名に置き換えます。
イメージを含む Quay.io リポジトリーを公開します。これによりイメージが公開され、Red Hat OpenShift Service on AWS クラスターに Pod をデプロイするために使用できるようになります。
- https://quay.io/ で、イメージを含むリポジトリーの Repository Settings ページに移動します。
- Make Public をクリックして、リポジトリーを公開します。
1.2.4. AWS SDK を含む Pod のデプロイ
AWS SDK を含むコンテナーイメージからユーザー定義プロジェクトに Pod をデプロイします。Pod 設定で、eks.amazonaws.com/role-arn アノテーションを含むサービスアカウントを指定します。
Pod のサービスアカウント参照が配置されると、Pod ID Webhook が AWS 環境変数、ボリュームマウント、およびトークンボリュームを Pod に挿入します。Pod のミューテーションにより、サービスアカウントは Pod で AWS IAM ロールを自動的に引き受けることができます。
前提条件
- サービスアカウントの AWS Identity and Access Management (IAM) ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc) がインストールされている。 -
サービスアカウントが引き受ける IAM ロールの Amazon Resource Name (ARN) を参照する
eks.amazonaws.com/role-arnアノテーションを含むサービスアカウントをプロジェクトに作成している。 AWS SDK を含むコンテナーイメージがあり、そのイメージをクラスターで使用できる。詳細な手順は、サンプルの AWS SDK コンテナーイメージの作成 を参照してください。
注記この手順例では、AWS Boto3 SDK for Python が使用されています。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
手順
次の Pod 設定で
awsboto3sdk-pod.yamlという名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: namespace: <project_name> 1 name: awsboto3sdk 2 spec: serviceAccountName: <service_account_name> 3 containers: - name: awsboto3sdk image: quay.io/<quay_username>/awsboto3sdk:latest 4 command: - /bin/bash - "-c" - "sleep 100000" 5 terminationGracePeriodSeconds: 0 restartPolicy: Never
- 1
<project-name>は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。- 2
- Pod の名前を指定します。
- 3
<service_account_name>を、AWS IAM ロールを引き受けるように設定されたサービスアカウントの名前に置き換えます。この名前は、AWS IAM ロールの設定で指定したサービスアカウント名と一致させる必要があります。- 4
awsboto3sdkコンテナーイメージの場所を指定します。<quay_username>を Quay.io ユーザー名に置き換えます。- 5
- この Pod 設定の例では、この行は Pod を 100000 秒間実行し続け、Pod で直接検証テストを有効にします。詳細な検証手順は、Pod で想定される IAM ロールの検証 を参照してください。
awsboto3sdkPod をデプロイします。$ oc create -f awsboto3sdk-pod.yaml
出力例:
pod/awsboto3sdk created
1.2.5. Pod で想定される IAM ロールを確認する
プロジェクトに awsboto3sdk Pod をデプロイした後、Pod ID Webhook が Pod を変更したことを確認します。必要な AWS 環境変数、ボリュームマウント、および OIDC トークンボリュームが Pod 内に存在することを確認します。
Pod で AWS SDK オペレーションを実行するときに、サービスアカウントが AWS アカウントの AWS Identity and Access Management (IAM) ロールを引き受けていることを確認することもできます。
前提条件
- サービスアカウントの AWS IAM ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc) がインストールされている。 -
サービスアカウントが引き受ける IAM ロールの Amazon Resource Name (ARN) を参照する
eks.amazonaws.com/role-arnアノテーションを含むサービスアカウントをプロジェクトに作成している。 AWS SDK を含むユーザー定義プロジェクトに Pod をデプロイしている。Pod は、Pod ID Webhook を使用するサービスアカウントを参照して、AWS SDK オペレーションの実行に必要な AWS IAM ロールを引き受けます。詳細な手順は、AWS SDK を含む Pod のデプロイ を参照してください。
注記この手順例では、AWS Boto3 SDK for Python を含む Pod が使用されます。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
手順
AWS 環境変数、ボリュームマウント、および OIDC トークンボリュームが、デプロイされた
awsboto3sdkPod の説明にリストされていることを確認します。$ oc describe pod awsboto3sdk
出力例:
Name: awsboto3sdk Namespace: <project_name> ... Containers: awsboto3sdk: ... Environment: AWS_ROLE_ARN: <aws_iam_role_arn> 1 AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token 2 Mounts: /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro) 3 ... Volumes: aws-iam-token: 4 Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 86400 ...- 1
- Pod ID Webhook によって Pod に挿入された
AWS_ROLE_ARN環境変数を一覧表示します。この変数には、サービスアカウントが引き受ける AWS IAM ロールの ARN が含まれます。 - 2
- Pod ID Webhook によって Pod に挿入された
AWS_WEB_IDENTITY_TOKEN_FILE環境変数を一覧表示します。この変数には、サービスアカウントの ID を確認するために使用される OIDC トークンの完全なパスが含まれています。 - 3
- Pod ID Webhook によって Pod に挿入されたボリュームマウントを一覧表示します。
- 4
/var/run/secrets/eks.amazonaws.com/serviceaccountマウントポイントにマウントされているaws-iam-tokenボリュームを一覧表示します。ボリュームには、AWS IAM ロールを引き受けるためにサービスアカウントを認証するために使用される OIDC トークンが含まれています。
awsboto3sdkPod でインタラクティブターミナルを起動します。$ oc exec -ti awsboto3sdk -- /bin/sh
Pod のインタラクティブターミナルで、Pod ID Webhook により
$AWS_ROLE_ARN環境変数が Pod に変更されたことを確認します。$ echo $AWS_ROLE_ARN
出力例:
arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name> 1- 1
- 出力では、AWS SDK オペレーションを実行するために必要なアクセス許可を持つ AWS IAM ロールの ARN を指定する必要があります。
Pod のインタラクティブターミナルで、Pod ID Webhook によって
$AWS_WEB_IDENTITY_TOKEN_FILE環境変数が Pod に変更されたことを確認します。$ echo $AWS_WEB_IDENTITY_TOKEN_FILE
出力例:
/var/run/secrets/eks.amazonaws.com/serviceaccount/token 1- 1
- 出力では、Pod 内のサービスアカウントの OIDC トークンへのフルパスを指定する必要があります。
Pod のインタラクティブターミナルで、OIDC トークンファイルを含む
aws-iam-tokenボリュームマウントが Pod ID Webhook によってマウントされたことを確認します。$ mount | grep -is 'eks.amazonaws.com'
出力例:
tmpfs on /run/secrets/eks.amazonaws.com/serviceaccount type tmpfs (ro,relatime,seclabel,size=13376888k)
Pod のインタラクティブターミナルで、
tokenという名前の OIDC トークンファイルが/var/run/secrets/eks.amazonaws.com/serviceaccount/マウントポイントに存在することを確認します。$ ls /var/run/secrets/eks.amazonaws.com/serviceaccount/token
出力例:
/var/run/secrets/eks.amazonaws.com/serviceaccount/token 1- 1
- Pod ID Webhook によって Pod にマウントされた
aws-iam-tokenボリューム内の OIDC トークンファイル。トークンは、AWS でサービスアカウントの ID を認証するために使用されます。
Pod で、AWS Boto3 SDK オペレーションが正常に実行されることを確認します。
Pod の対話型ターミナルで、Python 3 シェルを開始します。
$ python3
Python 3 シェルで、
boto3モジュールをインポートします。>>> import boto3
Boto3
s3サービスリソースを含む変数を作成します。>>> s3 = boto3.resource('s3')AWS アカウントのすべての S3 バケットの名前を出力します。
>>> for bucket in s3.buckets.all(): ... print(bucket.name) ...
出力例:
<bucket_name> <bucket_name> <bucket_name> ...
サービスアカウントが AWS IAM ロールを正常に引き受けた場合は、AWS アカウントで使用可能なすべての S3 バケットが出力に一覧表示されます。
1.3. 関連情報
- サービスアカウントで AWS IAM ロールを使用する方法の詳細は、AWS ドキュメントの サービスアカウントの IAM ロール を参照してください。
- AWS IAM ロールの委任は、AWS ドキュメントの AWS サービスにアクセス許可を委任するロールの作成 を参照してください。
- AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
- AWS Boto3 SDK for Python のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。
- OpenShift の Webhook アドミッションプラグインに関する一般的な情報は、OpenShift Container Platform ドキュメントの Webhook アドミッションプラグイン を参照してください。
第2章 Security Context Constraints の管理
Red Hat OpenShift Service on AWS では、SSC (Security Context Constraints) を使用して、クラスター内の Pod のアクセス許可を制御できます。
デフォルトの SCC は、インストール中、および一部の Operator またはその他のコンポーネントをインストールするときに作成されます。クラスター管理者は、OpenShift CLI (oc) を使用して独自の SCC を作成することもできます。
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、一部のプラットフォーム Pod がデプロイされるか、ROSA がアップグレードされるときに問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。
デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、セキュリティーコンテキスト制約の作成 を参照してください。
2.1. Security Context Constraints について
RBAC リソースがユーザーアクセスを制御するのと同じ方法で、管理者は Security Context Constraints (SCC) を使用して Pod のパーミッションを制御できます。これらのアクセス許可によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。
管理者は Security Context Constraints で、以下を制御できます。
-
Pod が
allowPrivilegedContainerフラグが付いた特権付きコンテナーを実行できるかどうか -
Pod が
allowPrivilegeEscalationフラグで制約されているかどうか - コンテナーが要求できる機能
- ホストディレクトリーのボリュームとしての使用
- コンテナーの SELinux コンテキスト
- コンテナーのユーザー ID
- ホストの namespace とネットワークの使用
-
Pod ボリュームを所有する
FSGroupの割り当て - 許可される補助グループの設定
- コンテナーが root ファイルシステムへの書き込みアクセスを必要とするかどうか
- ボリュームタイプの使用
-
許可される
seccompプロファイルの設定
Red Hat OpenShift Service on AWS の namespace には openshift.io/run-level ラベルを設定しないでください。このラベルは、Kubernetes API サーバーや OpenShift API サーバーなどのメジャー API グループの起動管理に、内部の Red Hat OpenShift Service on AWS コンポーネントで使用されます。openshift.io/run-level ラベルが設定される場合には対象の namespace の Pod に SCC が適用されず、その namespace で実行されるワークロードには高度な特権が割り当てられます。
2.1.1. デフォルトの Security Context Constraints
クラスターには、以下の表で説明されているように、デフォルトの SCC (Security Context Constraints) が複数含まれます。追加の SCC は、Operator または他のコンポーネントの Red Hat OpenShift Service on AWS へのインストール時にインストールされる可能性があります。
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、一部のプラットフォーム Pod がデプロイされるか、ROSA がアップグレードされるときに問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。
デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、セキュリティーコンテキスト制約の作成 を参照してください。
表2.1 デフォルトの Security Context Constraints
| SCC (Security Context Constraints) | 説明 |
|---|---|
|
|
SCC のすべての機能が |
|
| ホストの全 namespace にアクセスできますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。 警告 この SCC で、ホストは namespace、ファイルシステム、および PID にアクセスできます。信頼できる Pod だけがこの SCC を使用する必要があります。付与には注意が必要です。 |
|
|
SCC のすべての機能を 警告 この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。 |
|
| ホストのネットワークおよびホストポートを使用できますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。 警告
追加のワークロードをコントロールプレーンホストで実行する場合は、 |
|
|
|
|
| Prometheus ノードエクスポーターに使用されます。 警告 この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。 |
|
|
SCC のすべての機能が |
|
|
|
|
| すべての特権およびホスト機能にアクセスでき、任意のユーザー、任意のグループ、FSGroup、および任意の SELinux コンテキストで実行できます。 警告 これは最も制限の少ない SCC であり、クラスター管理にのみ使用してください。付与には注意が必要です。
注記
Pod の仕様で |
|
| すべてのホスト機能へのアクセスが拒否され、Pod を UID および namespace に割り当てられる SELinux コンテキストで実行する必要があります。
Red Hat OpenShift Service on AWS 4.10 以前からアップグレードされたクラスターでは、すべての認証済みユーザーがこの SCC を使用できます。アクセスが明示的に付与されない限り、新しい Red Hat OpenShift Service on AWS 4.11 以降のインストールのユーザーは |
|
|
これは新規インストールで提供され、デフォルトで認証済みユーザーに使用される最も制限の厳しい SCC です。 注記
|
2.1.2. Security Context Constraints の設定
Security Context Constraints (SCC) は、Pod がアクセスできるセキュリティー機能を制御する設定およびストラテジーで設定されています。これらの設定は以下のカテゴリーに分類されます。
| カテゴリー | 説明 |
|---|---|
| ブール値による制御 |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
| 許可されるセットによる制御 | このタイプのフィールドがセットに対してチェックされ、その値が許可されることを確認します。 |
| ストラテジーによる制御 | 値を生成するストラテジーを持つ項目は以下を提供します。
|
CRI-O には、Pod の各コンテナーについて許可されるデフォルトの機能一覧があります。
-
CHOWN -
DAC_OVERRIDE -
FSETID -
FOWNER -
SETGID -
SETUID -
SETPCAP -
NET_BIND_SERVICE -
KILL
コンテナーはこのデフォルト一覧から機能を使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルト動作の一部を削除して一覧を変更できます。allowedCapabilities パラメーター、defaultAddCapabilities パラメーター、および requiredDropCapabilities パラメーターを使用して、Pod からのこのような要求を制御します。これらのパラメーターを使用して、(各コンテナーに追加する必要のある機能や、各コンテナーから禁止または破棄する必要のあるものなど) 要求できる機能を指定できます。
requiredDropCapabilities パラメーターを ALL に設定すると、すべての capabilites をコンテナーから取り除くことができます。これは、restricted-v2 SCC の機能です。
2.1.3. Security Context Constraints ストラテジー
RunAsUser
MustRunAs:runAsUserが設定されることを要求します。デフォルトで設定済みのrunAsUserを使用します。設定済みのrunAsUserに対して検証します。MustRunAsスニペットの例... runAsUser: type: MustRunAs uid: <id> ...
MustRunAsRange: 事前に割り当てられた値を使用していない場合に、最小値および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。MustRunAsRangeスニペットの例... runAsUser: type: MustRunAsRange uidRangeMax: <maxvalue> uidRangeMin: <minvalue> ...
MustRunAsNonRoot: Pod がゼロ以外のrunAsUserで送信されること、またはUSERディレクティブをイメージに定義することを要求します。デフォルトは指定されません。MustRunAsNonRootスニペットの例... runAsUser: type: MustRunAsNonRoot ...
RunAsAny: デフォルトは指定されません。runAsUserの指定を許可します。RunAsAnyスニペットの例... runAsUser: type: RunAsAny ...
SELinuxContext
-
MustRunAs: 事前に割り当てられた値を使用していない場合にseLinuxOptionsが設定されることを要求します。デフォルトとしてseLinuxOptionsを使用します。seLinuxOptionsに対して検証します。 -
RunAsAny: デフォルトは指定されません。seLinuxOptionsの指定を許可します。
SupplementalGroups
-
MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。 -
RunAsAny: デフォルトは指定されません。supplementalGroupsの指定を許可します。
FSGroup
-
MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。 -
RunAsAny: デフォルトは指定されません。fsGroupID の指定を許可します。
2.1.4. ボリュームの制御
特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。
このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。
-
awsElasticBlockStore -
azureDisk -
azureFile -
cephFS -
cinder -
configMap -
csi -
downwardAPI -
emptyDir -
fc -
flexVolume -
flocker -
gcePersistentDisk -
gitRepo -
glusterfs -
hostPath -
iscsi -
nfs -
persistentVolumeClaim -
photonPersistentDisk -
portworxVolume -
projected -
quobyte -
rbd -
scaleIO -
secret -
storageos -
vsphereVolume - * (すべてのボリュームタイプの使用を許可する特殊な値)
-
none(すべてのボリュームタイプの使用を無効にする特殊な値。後方互換の場合にのみ存在する)
新規 SCC について許可されるボリュームの推奨される最小セットは、configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret、および projected です。
Red Hat OpenShift Service on AWS の各リリースに新しいタイプ追加されるため、この許可されるボリュームタイプ一覧がすべて網羅しているわけではありません。
後方互換性を確保するため、allowHostDirVolumePlugin の使用は volumes フィールドの設定をオーバーライドします。たとえば、allowHostDirVolumePlugin が false に設定されていて、volumes フィールドで許可されている場合は、volumes から hostPath 値が削除されます。
2.1.5. 受付制御
SCC が設定された 受付制御 により、ユーザーに付与された機能に基づいてリソースの作成に対する制御が可能になります。
SCC の観点では、これは受付コントローラーが、SCC の適切なセットを取得するためにコンテキストで利用可能なユーザー情報を検査できることを意味します。これにより、Pod はその運用環境についての要求を行ったり、Pod に適用する一連の制約を生成したりする権限が与えられます
受付が Pod を許可するために使用する SCC のセットはユーザーアイデンティティーおよびユーザーが属するグループによって決定されます。さらに、Pod がサービスアカウントを指定する場合は、許可される SCC のセットに、サービスアカウントでアクセスできる制約が含まれます。
受付は以下の方法を使用して、Pod の最終的なセキュリティーコンテキストを作成します。
- 使用できるすべての SCC を取得します。
- 要求に指定されていないセキュリティーコンテキストに、設定のフィールド値を生成します。
- 利用可能な制約に対する最終的な設定を検証します。
制約の一致するセットが検出される場合は、Pod が受け入れられます。要求が SCC に一致しない場合は、Pod が拒否されます。
Pod はすべてのフィールドを SCC に対して検証する必要があります。以下は、検証する必要のある 2 つのフィールドのみについての例になります。
これらの例は、事前に割り当てられた値を使用するストラテジーに関連します。
MustRunAs の FSGroup SCC ストラテジー
Pod が fsGroup ID を定義する場合、その ID はデフォルトの fsGroup ID に等しくなければなりません。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.fsGroup フィールドに値 RunAsAny があり、Pod 仕様が Pod.spec.securityContext.fsGroup を省略すると、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
MustRunAs の SupplementalGroups SCC ストラテジー
Pod 仕様が 1 つ以上の supplementalGroups ID を定義する場合、Pod の ID は namespace の openshift.io/sa.scc.supplemental-groups アノテーションの ID のいずれかに等しくなければなりません。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.supplementalGroups フィールドに値 RunAsAny があり、Pod 仕様が Pod.spec.securityContext.supplementalGroups を省略する場合、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
2.1.6. Security Context Constraints の優先度設定
SCC (Security Context Constraints) には優先度フィールドがあり、受付コントローラーの要求検証を試行する順序に影響を与えます。
優先順位値 0 は可能な限り低い優先順位です。nil 優先順位は 0 または最低の優先順位と見なされます。優先順位の高い SCC は、並べ替え時にセットの先頭に移動します。
使用可能な SCC の完全なセットが決定すると、SCC は次の方法で順序付けられます。
- 最も優先度の高い SCC が最初に並べられます。
- 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
- 優先度と制限の両方が等しい場合、SCC は名前でソートされます。
デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContext で RunAsUser を指定することにより、任意のユーザーとして Pod を実行できます。
2.2. 事前に割り当てられる Security Context Constraints 値について
受付コントローラーは、これが namespace の事前に割り当てられた値を検索し、Pod の処理前に Security Context Constraints (SCC) を設定するようにトリガーする SCC (Security Context Constraint) の特定の条件を認識します。各 SCC ストラテジーは他のストラテジーとは別に評価されます。この際、(許可される場合に) Pod 仕様の値と共に集計された各ポリシーの事前に割り当てられた値が使用され、実行中の Pod で定義される各種 ID の最終の値が設定されます。
以下の SCC により、受付コントローラーは、範囲が Pod 仕様で定義されていない場合に事前に定義された値を検索できます。
-
最小または最大値が設定されていない
MustRunAsRangeのRunAsUserストラテジーです。受付はopenshift.io/sa.scc.uid-rangeアノテーションを検索して範囲フィールドを設定します。 -
レベルが設定されていない
MustRunAsのSELinuxContextストラテジーです。受付はopenshift.io/sa.scc.mcsアノテーションを検索してレベルを設定します。 -
MustRunAsのFSGroupストラテジーです。受付は、openshift.io/sa.scc.supplemental-groupsアノテーションを検索します。 -
MustRunAsのSupplementalGroupsストラテジーです。受付は、openshift.io/sa.scc.supplemental-groupsアノテーションを検索します。
生成フェーズでは、セキュリティーコンテキストのプロバイダーが Pod にとくに設定されていないパラメーター値をデフォルト設定します。デフォルト設定は選択されるストラテジーに基づいて行われます。
-
RunAsAnyおよびMustRunAsNonRootストラテジーはデフォルトの値を提供しません。Pod がパラメーター値 (グループ ID など) を必要とする場合は、値を Pod 仕様内に定義する必要があります。 -
MustRunAs(単一の値) ストラテジーは、常に使用されるデフォルト値を提供します。たとえば、グループ ID の場合は、Pod 仕様が独自の ID 値を定義する場合でも、namespace のデフォルトパラメーター値が Pod のグループに表示されます。 -
MustRunAsRangeおよびMustRunAs(範囲ベース) ストラテジーは、範囲の最小値を提供します。単一値のMustRunAsストラテジーの場合のように、namespace のデフォルト値は実行中の Pod に表示されます。範囲ベースのストラテジーが複数の範囲で設定可能な場合、これは最初に設定された範囲の最小値を指定します。
FSGroup および SupplementalGroups ストラテジーは、openshift.io/sa.scc.supplemental-groups アノテーションが namespace に存在しない場合に openshift.io/sa.scc.uid-range アノテーションにフォールバックします。いずれも存在しない場合は、SCC が作成されません。
デフォルトで、アノテーションベースの FSGroup ストラテジーは、自身をアノテーションの最小値に基づく単一の範囲で設定します。たとえば、アノテーションが 1/3 を読み取ると、FSGroup ストラテジーは 1 の最小値および最大値で自身を設定します。追加のグループを FSGroup フィールドで許可する必要がある場合は、アノテーションを使用しないカスタム SCC を設定することができます。
openshift.io/sa.scc.supplemental-groups アノテーションは、<start>/<length または <start>-<end> 形式のコンマ区切りのブロックの一覧を受け入れます。openshift.io/sa.scc.uid-range アノテーションは単一ブロックのみを受け入れます。
2.3. Security Context Constraints の例
以下の例は、Security Context Constraints (SCC) 形式およびアノテーションを示しています。
注釈付き privileged SCC
allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegedContainer: true allowedCapabilities: 1 - '*' apiVersion: security.openshift.io/v1 defaultAddCapabilities: [] 2 fsGroup: 3 type: RunAsAny groups: 4 - system:cluster-admins - system:nodes kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: 'privileged allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context. WARNING: this is the most relaxed SCC and should be used only for cluster administration. Grant with caution.' creationTimestamp: null name: privileged priority: null readOnlyRootFilesystem: false requiredDropCapabilities: 5 - KILL - MKNOD - SETUID - SETGID runAsUser: 6 type: RunAsAny seLinuxContext: 7 type: RunAsAny seccompProfiles: - '*' supplementalGroups: 8 type: RunAsAny users: 9 - system:serviceaccount:default:registry - system:serviceaccount:default:router - system:serviceaccount:openshift-infra:build-controller volumes: 10 - '*'
- 1
- Pod が要求できる機能の一覧です。特殊な記号
*は任意の機能を許可しますが、一覧が空の場合は、いずれの機能も要求できないことを意味します。 - 2
- Pod に含める追加機能の一覧です。
- 3
- セキュリティーコンテキストの許可される値を定める
FSGroupストラテジータイプです。 - 4
- この SCC へのアクセスを持つグループです。
- 5
- Pod から取り除く機能の一覧です。または、
ALLを指定してすべての機能をドロップします。 - 6
- セキュリティーコンテキストの許可される値を定める
runAsUserストラテジータイプです。 - 7
- セキュリティーコンテキストの許可される値を定める
seLinuxContextストラテジータイプです。 - 8
- セキュリティーコンテキストの許可される補助グループを定める
supplementalGroupsストラテジーです。 - 9
- この SCC にアクセスできるユーザーです。
- 10
- セキュリティーコンテキストで許容されるボリュームタイプです。この例では、
*はすべてのボリュームタイプの使用を許可します。
SCC の users フィールドおよび groups フィールドは SCC にアクセスできるユーザー制御します。デフォルトで、クラスター管理者、ノードおよびビルドコントローラーに特権付き SCC へのアクセスが付与されます。認証されたすべてのユーザーには restricted-v2 SCC へのアクセスが付与されます。
明示的な runAsUser 設定を使用しない場合
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext: 1
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
- 1
- コンテナーまたは Pod が実行時に使用するユーザー ID を要求しない場合、有効な UID はこの Pod を作成する SCC よって異なります。
restricted-v2SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。restricted-v2SCC は、securityContext.runAsUserフィールドの使用できる値を制限し、これをデフォルトに設定するためにMustRunAsRangeストラテジーを使用します。受付プラグインではこの範囲を指定しないため、現行プロジェクトでopenshift.io/sa.scc.uid-rangeアノテーションを検索して範囲フィールドにデータを設定します。最終的にコンテナーのrunAsUserは予測が困難な範囲の最初の値と等しい値になります。予測が困難であるのはすべてのプロジェクトにはそれぞれ異なる範囲が設定されるためです。
明示的な runAsUser 設定を使用する場合
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000 1
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
- 1
- 特定のユーザー ID を要求するコンテナーまたは Pod が Red Hat OpenShift Container Platform on AWS で受け入れられるのは、サービスアカウントまたはユーザーに、そのユーザー ID を許可するように、SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。
この設定は、SELinux、fsGroup、および Supplemental Groups について有効です。
2.4. セキュリティーコンテキスト制約の作成
OpenShift CLI (oc) を使用して Security Context Constraints (SCC) を作成できます。
独自の SCC の作成と変更は高度な操作であり、クラスターを不安定にする可能性があります。独自の SCC の使用について質問がある場合は、Red Hat サポートにお問い合わせください。Red Hat サポートへの連絡方法は、サポートを受ける方法 を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインしている。
手順
scc-admin.yamlという名前の YAML ファイルで SCC を定義します。kind: SecurityContextConstraints apiVersion: security.openshift.io/v1 metadata: name: scc-admin allowPrivilegedContainer: true runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny fsGroup: type: RunAsAny supplementalGroups: type: RunAsAny users: - my-admin-user groups: - my-admin-group
オプションとして、
requiredDropCapabilitiesフィールドに必要な値を設定して、SCC の特定の機能を取り除くことができます。指定された機能はコンテナーからドロップされます。すべてのケイパビリティーを破棄するには、ALLを指定します。たとえば、KILL機能、MKNOD機能、およびSYS_CHROOT機能のない SCC を作成するには、以下を SCC オブジェクトに追加します。requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT
注記allowedCapabilitiesとrequiredDropCapabilitiesの両方に、機能を追加できません。CRI-O は、Docker ドキュメント に記載されている同じ一連の機能の値をサポートし ます。
ファイルを渡して SCC を作成します。
$ oc create -f scc-admin.yaml
出力例
securitycontextconstraints "scc-admin" created
検証
SCC が作成されていることを確認します。
$ oc get scc scc-admin
出力例
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]
2.5. Security Context Constraints へのロールベースのアクセス
SCC は RBAC で処理されるリソースとして指定できます。これにより、SCC へのアクセスのスコープを特定プロジェクトまたはクラスター全体に設定できます。ユーザー、グループ、またはサービスアカウントを SCC に直接割り当てると、クラスター全体のスコープが保持されます。
SCC をデフォルト namespace (default、kube-system、kube-public、openshift-node、openshift-infra、および openshift) のいずれかに作成します。これらの namespace は Pod またはサービスの実行に使用しないでください。
ロールの SCC へのアクセスを組み込むには、ロールの作成時に scc リソースを指定します。
$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>
これにより、以下のロール定義が生成されます。
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: ... name: role-name 1 namespace: namespace 2 ... rules: - apiGroups: - security.openshift.io 3 resourceNames: - scc-name 4 resources: - securitycontextconstraints 5 verbs: 6 - use
このようなルールを持つローカルまたはクラスターロールは、ロールバインディングまたはクラスターロールバインディングでこれにバインドされたサブジェクトが scc-name というユーザー定義の SCC を使用することを許可します。
RBAC はエスカレーションを防ぐように設計されているため、プロジェクト管理者であっても SCC へのアクセスを付与することはできません。デフォルトでは、restricted-v2 SCC を含め、SCC リソースで動詞 use を使用することは許可されていません。
2.6. Security Context Constraints コマンドのリファレンス
OpenShift CLI (oc) を使用して、インスタンスの Security Context Constraints (SCC) を通常の API オブジェクトとして管理できます。
2.6.1. Security Context Constraints の表示
SCC の現在の一覧を取得するには、以下を実行します。
$ oc get scc
出力例
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny 10 false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] hostaccess false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","persistentVolumeClaim","projected","secret"] hostmount-anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","nfs","persistentVolumeClaim","projected","secret"] hostnetwork false <no value> MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] hostnetwork-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] node-exporter true <no value> RunAsAny RunAsAny RunAsAny RunAsAny <no value> false ["*"] nonroot false <no value> MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] nonroot-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] privileged true ["*"] RunAsAny RunAsAny RunAsAny RunAsAny <no value> false ["*"] restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"] restricted-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
2.6.2. Security Context Constraints の検証
特定の SCC に関する情報 (SCC が適用されるユーザー、サービスアカウントおよびグループを含む) を表示できます。
たとえば、restricted SCC を検査するには、以下を実行します。
$ oc describe scc restricted
出力例
Name: restricted Priority: <none> Access: Users: <none> 1 Groups: <none> 2 Settings: Allow Privileged: false Allow Privilege Escalation: true Default Add Capabilities: <none> Required Drop Capabilities: KILL,MKNOD,SETUID,SETGID Allowed Capabilities: <none> Allowed Seccomp Profiles: <none> Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret Allowed Flexvolumes: <all> Allowed Unsafe Sysctls: <none> Forbidden Sysctls: <none> Allow Host Network: false Allow Host Ports: false Allow Host PID: false Allow Host IPC: false Read Only Root Filesystem: false Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: <none> UID Range Max: <none> SELinux Context Strategy: MustRunAs User: <none> Role: <none> Type: <none> Level: <none> FSGroup Strategy: MustRunAs Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>