認証および認可

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS クラスターのセキュリティー保護

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) クラスターのセキュリティー保護を説明します。

第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 ワークフロー

Pod identity webhook workflow

ワークフローには次の段階があります。

  1. ユーザー定義のプロジェクト内で、ユーザーは eks.amazonaws.com/role-arn アノテーションを含むサービスアカウントを作成します。アノテーションは、サービスアカウントが引き受ける AWS IAM ロールの ARN を指します。
  2. アノテーション付きのサービスアカウントを参照する設定を使用して 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 トークンファイルがボリュームに含まれています。
  3. 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 が含まれています。
  4. プロジェクトとサービスアカウントが、引き受ける IAM ロールの信頼ポリシーのスコープ内にある場合は、認可が成功します。
  5. 認証と認可が成功すると、セッショントークンの形式の一時的な AWS STS 認証情報が Pod に渡され、サービスアカウントで使用できるようになります。認証情報を使用することで、IAM ロールで有効になっている AWS アクセス許可がサービスアカウントに一時的に付与されます。
  6. 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) をインストールしている。

手順

  1. 次の 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>:*" を使用して、指定したプロジェクト内の任意のサービスアカウントにロールを制限できます。* ワイルドカードを指定する場合は、前の行で StringEqualsStringLike に置き換える必要があります。

  2. 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
    1
    <aws_iam_role_name>pod-identity-test-role などの IAM ロールの名前に置き換えます。
    2
    前の手順で作成した trust-policy.json ファイルを参照します。

    出力例:

    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> です。

  3. サービスアカウントが 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
    1
    この例のポリシーは、IAM ロールに読み取り専用アクセス許可を追加します。
    2
    <aws_iam_role_name> を、前のステップで作成した IAM ロールの名前に置き換えます。
  4. オプション: カスタム属性または権限境界をロールに追加します。詳細は、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) がインストールされている。

手順

  1. Red Hat OpenShift Service on AWS クラスターで、プロジェクトを作成します。

    $ oc new-project <project_name> 1
    1
    <project-name> は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。
    注記

    プロジェクトが作成されると、自動的にプロジェクトに切り替わります。

  2. 次のサービスアカウント設定で、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> です。
  3. プロジェクトにサービスアカウントを作成します。

    $ oc create -f test-service-account.yaml

    出力例:

    serviceaccount/<service_account_name> created

  4. サービスアカウントの詳細を確認します。

    $ 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 IAM ロールの ARN のアノテーションを一覧表示します。

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 ユーザーアカウントを持っている。

手順

  1. 次の設定を Containerfile という名前のファイルに追加します。

    FROM ubi9/ubi 1
    RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0 2
    1
    Red Hat Universal Base Image バージョン 9 を指定します。
    2
    pip パッケージ管理システムを使用して AWS Boto3 SDK をインストールします。この例では、AWS Boto3 SDK バージョン 1.15.0 以降がインストールされています。
  2. ファイルを含むディレクトリーから、awsboto3sdk という名前のコンテナーイメージをビルドします。

    $ podman build -t awsboto3sdk .
  3. Quay.io にログインします。

    $ podman login quay.io
  4. Quay.io へのアップロードの準備として、イメージにタグを付けます。

    $ podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest 1
    1
    <quay_username> を Quay.io ユーザー名に置き換えます。
  5. タグ付けされたコンテナーイメージを Quay.io にプッシュします。

    $ podman push quay.io/<quay_username>/awsboto3sdk:latest 1
    1
    <quay_username> を Quay.io ユーザー名に置き換えます。
  6. イメージを含む Quay.io リポジトリーを公開します。これによりイメージが公開され、Red Hat OpenShift Service on AWS クラスターに Pod をデプロイするために使用できるようになります。

    1. https://quay.io/ で、イメージを含むリポジトリーの Repository Settings ページに移動します。
    2. 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 を参照してください。

手順

  1. 次の 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 ロールの検証 を参照してください。
  2. awsboto3sdk Pod をデプロイします。

    $ 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 を参照してください。

手順

  1. AWS 環境変数、ボリュームマウント、および OIDC トークンボリュームが、デプロイされた awsboto3sdk Pod の説明にリストされていることを確認します。

    $ 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 トークンが含まれています。
  2. awsboto3sdk Pod でインタラクティブターミナルを起動します。

    $ oc exec -ti awsboto3sdk -- /bin/sh
  3. 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 を指定する必要があります。
  4. 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 トークンへのフルパスを指定する必要があります。
  5. 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)

  6. 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 を認証するために使用されます。
  7. Pod で、AWS Boto3 SDK オペレーションが正常に実行されることを確認します。

    1. Pod の対話型ターミナルで、Python 3 シェルを開始します。

      $ python3
    2. Python 3 シェルで、boto3 モジュールをインポートします。

      >>> import boto3
    3. Boto3 s3 サービスリソースを含む変数を作成します。

      >>> s3 = boto3.resource('s3')
    4. AWS アカウントのすべての S3 バケットの名前を出力します。

      >>> for bucket in s3.buckets.all():
      ...     print(bucket.name)
      ...

      出力例:

      <bucket_name>
      <bucket_name>
      <bucket_name>
      ...

      サービスアカウントが AWS IAM ロールを正常に引き受けた場合は、AWS アカウントで使用可能なすべての S3 バケットが出力に一覧表示されます。

1.3. 関連情報

第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)説明

anyuid

SCC のすべての機能が restricted で提供されますが、ユーザーは任意の UID と GID で実行できます。

hostaccess

ホストの全 namespace にアクセスできますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。

警告

この SCC で、ホストは namespace、ファイルシステム、および PID にアクセスできます。信頼できる Pod だけがこの SCC を使用する必要があります。付与には注意が必要です。

hostmount-anyuid

SCC のすべての機能を restricted で提供しますが、ホストのマウントとシステム上の任意の UID および GID として実行できます。

警告

この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。

hostnetwork

ホストのネットワークおよびホストポートを使用できますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。

警告

追加のワークロードをコントロールプレーンホストで実行する場合は、hostnetwork へのアクセスを割り当てるときに注意してください。コントロールプレーンホストで hostnetwork を実行するワークロードにはクラスター上で root アクセスを持つユーザーと同じ機能があるため、適切に信頼されている必要があります。

hostnetwork-v2

hostnetwork SCC と似ていますが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

node-exporter

Prometheus ノードエクスポーターに使用されます。

警告

この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。

nonroot

SCC のすべての機能が restricted で提供されますが、ユーザーは root 以外の UID で実行できます。ユーザーは UID を指定するか、コンテナーランタイムのマニフェストに指定する必要があります。

nonroot-v2

nonroot SCC と同様ですが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

privileged

すべての特権およびホスト機能にアクセスでき、任意のユーザー、任意のグループ、FSGroup、および任意の SELinux コンテキストで実行できます。

警告

これは最も制限の少ない SCC であり、クラスター管理にのみ使用してください。付与には注意が必要です。

privileged SCC は以下を許可します。

  • ユーザーによる特権付き Pod の実行
  • Pod によるホストディレクトリーのボリュームとしてのマウント
  • Pod の任意ユーザーとしての実行
  • Pod の MCS ラベルの使用による実行
  • Pod によるホストの IPC namespace の使用
  • Pod によるホストの PID namespace の使用
  • Pod による FSGroup の使用
  • Pod による補助グループの使用
  • Pod による seccomp プロファイルの使用
  • Pod による機能の要求
注記

Pod の仕様で privileged: true を設定しても、privileged SCC が選択されるとは限りません。ユーザーに使用権限がある場合に、allowPrivilegedContainer: true が指定されており、優先順位が最も高い SCC が選択されます。

restricted

すべてのホスト機能へのアクセスが拒否され、Pod を UID および namespace に割り当てられる SELinux コンテキストで実行する必要があります。

restricted SCC は以下を実行します。

  • Pod が特権付きで実行されないようにします。
  • Pod がホストディレクトリーボリュームをマウントできないようにします。
  • Pod が事前に割り当てられた UID 範囲のユーザーとして実行することを要求します。
  • Pod が事前に割り当てられた MCS ラベルで実行されることを要求します。
  • Pod が FSGroup を使用することを許可します。
  • Pod が補助グループを使用することを許可します。

Red Hat OpenShift Service on AWS 4.10 以前からアップグレードされたクラスターでは、すべての認証済みユーザーがこの SCC を使用できます。アクセスが明示的に付与されない限り、新しい Red Hat OpenShift Service on AWS 4.11 以降のインストールのユーザーは restricted SCC を使用できなくなります。

restricted-v2

restricted SCC と同様ですが、次の違いがあります。

  • ALL 機能がコンテナーから削除されます。
  • NET_BIND_SERVICE 機能を明示的に追加できます。
  • seccompProfile はデフォルトで runtime/default に設定されています。
  • セキュリティーコンテキストでは、allowPrivilegeEscalation を設定解除するか、false に設定する必要があります。

これは新規インストールで提供され、デフォルトで認証済みユーザーに使用される最も制限の厳しい SCC です。

注記

restricted-v2 SCC は、システムにデフォルトで含まれている SCC の中で最も制限が厳しいものです。ただし、さらに制限の厳しいカスタム SCC を作成できます。たとえば、readOnlyRootFilesystemtrue に制限する SCC を作成できます。

2.1.2. Security Context Constraints の設定

Security Context Constraints (SCC) は、Pod がアクセスできるセキュリティー機能を制御する設定およびストラテジーで設定されています。これらの設定は以下のカテゴリーに分類されます。

カテゴリー説明

ブール値による制御

このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、AllowPrivilegedContainer が指定されていない場合は、false に常に設定されます。

許可されるセットによる制御

このタイプのフィールドがセットに対してチェックされ、その値が許可されることを確認します。

ストラテジーによる制御

値を生成するストラテジーを持つ項目は以下を提供します。

  • 値を生成するメカニズム
  • 指定された値が許可される値のセットに属するようにするメカニズム

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: デフォルトは指定されません。fsGroup ID の指定を許可します。

2.1.4. ボリュームの制御

特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。

このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。

新規 SCC について許可されるボリュームの推奨される最小セットは、configMapdownwardAPIemptyDirpersistentVolumeClaimsecret、および 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 の最終的なセキュリティーコンテキストを作成します。

  1. 使用できるすべての SCC を取得します。
  2. 要求に指定されていないセキュリティーコンテキストに、設定のフィールド値を生成します。
  3. 利用可能な制約に対する最終的な設定を検証します。

制約の一致するセットが検出される場合は、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 を失敗させる可能性があることに注意してください。

MustRunAsSupplementalGroups 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 は次の方法で順序付けられます。

  1. 最も優先度の高い SCC が最初に並べられます。
  2. 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
  3. 優先度と制限の両方が等しい場合、SCC は名前でソートされます。

デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContextRunAsUser を指定することにより、任意のユーザーとして Pod を実行できます。

2.2. 事前に割り当てられる Security Context Constraints 値について

受付コントローラーは、これが namespace の事前に割り当てられた値を検索し、Pod の処理前に Security Context Constraints (SCC) を設定するようにトリガーする SCC (Security Context Constraint) の特定の条件を認識します。各 SCC ストラテジーは他のストラテジーとは別に評価されます。この際、(許可される場合に) Pod 仕様の値と共に集計された各ポリシーの事前に割り当てられた値が使用され、実行中の Pod で定義される各種 ID の最終の値が設定されます。

以下の SCC により、受付コントローラーは、範囲が Pod 仕様で定義されていない場合に事前に定義された値を検索できます。

  1. 最小または最大値が設定されていない MustRunAsRangeRunAsUser ストラテジーです。受付は openshift.io/sa.scc.uid-range アノテーションを検索して範囲フィールドを設定します。
  2. レベルが設定されていない MustRunAsSELinuxContext ストラテジーです。受付は openshift.io/sa.scc.mcs アノテーションを検索してレベルを設定します。
  3. MustRunAsFSGroup ストラテジーです。受付は、openshift.io/sa.scc.supplemental-groups アノテーションを検索します。
  4. MustRunAsSupplementalGroups ストラテジーです。受付は、openshift.io/sa.scc.supplemental-groups アノテーションを検索します。

生成フェーズでは、セキュリティーコンテキストのプロバイダーが Pod にとくに設定されていないパラメーター値をデフォルト設定します。デフォルト設定は選択されるストラテジーに基づいて行われます。

  1. RunAsAny および MustRunAsNonRoot ストラテジーはデフォルトの値を提供しません。Pod がパラメーター値 (グループ ID など) を必要とする場合は、値を Pod 仕様内に定義する必要があります。
  2. MustRunAs (単一の値) ストラテジーは、常に使用されるデフォルト値を提供します。たとえば、グループ ID の場合は、Pod 仕様が独自の ID 値を定義する場合でも、namespace のデフォルトパラメーター値が Pod のグループに表示されます。
  3. 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-v2 SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。restricted-v2 SCC は、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 ロールを持つユーザーとしてクラスターにログインしている。

手順

  1. 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
    注記

    allowedCapabilitiesrequiredDropCapabilities の両方に、機能を追加できません。

    CRI-O は、Docker ドキュメント に記載されている同じ一連の機能の値をサポートし ます。

  2. ファイルを渡して 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 (defaultkube-systemkube-publicopenshift-nodeopenshift-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
1
ロールの名前。
2
定義されたロールの namespace。指定されていない場合は、default にデフォルト設定されます。
3
SecurityContextConstraints リソースを含む API グループ。scc がリソースとして指定される場合に自動的に定義されます。
4
アクセスできる SCC の名前のサンプル。
5
ユーザーが SCC 名を resourceNames フィールドに指定することを許可するリソースグループの名前。
6
ロールに適用する動詞の一覧。

このようなルールを持つローカルまたはクラスターロールは、ロールバインディングまたはクラスターロールバインディングでこれにバインドされたサブジェクトが 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>

1
SCC が適用されるユーザーとサービスアカウントを一覧表示します。
2
SCC が適用されるグループを一覧表示します。

2.7. 関連情報

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.