Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第15章 SCC (Security Context Constraints) の管理

15.1. 概要
リンクのコピー

SCC (Security Context Constraints) により、管理者は Pod のパーミッションを制御できます。この API タイプについての詳細は、SCC (security context constraints) アーキテクチャーのドキュメントを参照してください。SCC は、CLI を使用し、インスタンスで通常の API オブジェクトとして管理できます。

注記

SCC を管理するには、cluster-admin 権限が必要です。

重要

デフォルトの SCC を変更しないでください。デフォルトの SCC をカスタマイズすると、アップグレード時に問題が生じる可能性があります。代わりに 新規 SCC を作成してください。

15.2. SCC (Security Context Constraints) の一覧表示
リンクのコピー

SCC の現在の一覧を取得するには、以下を実行します。 

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
Copy to Clipboard Toggle word wrap

15.3. SCC (Security Context Constraints) オブジェクトの検査
リンクのコピー

特定の SCC を検査するには、oc get、oc describe、oc export、または oc edit を使用します。たとえば、restricted SCC を検査するには、以下を実行します。 

$ oc describe scc restricted
Name:					restricted
Priority:				<none>
Access:
  Users:				<none>
  Groups:				system:authenticated
Settings:
  Allow Privileged:			false
  Default Add Capabilities:		<none>
  Required Drop Capabilities:		KILL,MKNOD,SYS_CHROOT,SETUID,SETGID
  Allowed Capabilities:			<none>
  Allowed Seccomp Profiles:		<none>
  Allowed Volume Types:			configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  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>
Copy to Clipboard Toggle word wrap
注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ、ラベル、およびアノテーション以外にはデフォルトの SCC の設定を編集しないでください。

15.4. 新規 SCC (Security Context Constraints) の作成
リンクのコピー

新規 SCC を作成するには、以下を実行します。

  1. JSON または YAML ファイルで SCC を定義します。

    SCC (Security Context Constraints) オブジェクトの定義

    kind: SecurityContextConstraints
apiVersion: 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
    Copy to Clipboard Toggle word wrap

    オプションとして、requiredDropCapabilities フィールドに必要な値を設定してドロップ機能を SCC に追加することができます。指定された機能はコンテナーからドロップされることになります。たとえば、SCC を KILL、MKNOD、および SYS_CHROOT の必要なドロップ機能を使って作成するには、以下を SCC オブジェクトに追加します。 

    requiredDropCapabilities:
- KILL
- MKNOD
- SYS_CHROOT
    Copy to Clipboard Toggle word wrap

    使用できる値の一覧は、Docker ドキュメントで確認できます。

    ヒント

    機能は Docker に渡されるため、特殊な ALL 値を使用してすべての機能をドロップすることができます。

  2. 次に、作成するファイルを渡して oc create を実行します。 

    $ oc create -f scc_admin.yaml
securitycontextconstraints "scc-admin" created
    Copy to Clipboard Toggle word wrap

  3. 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]
    Copy to Clipboard Toggle word wrap

15.5. SCC (Security Context Constraints) の削除
リンクのコピー

SCC を削除するには、以下を実行します。 

$ oc delete scc <scc_name>
Copy to Clipboard Toggle word wrap
注記

デフォルトの SCC を削除する場合、これは再起動時に再生成されます。

15.6. SCC (Security Context Constraints) の更新
リンクのコピー

既存 SCC を更新するには、以下を実行します。 

$ oc edit scc <scc_name>
Copy to Clipboard Toggle word wrap
注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ以外にデフォルトの SCC の設定を編集しないでください。

15.6.1. SCC (Security Context Constraints) 設定のサンプル
リンクのコピー

明示的な 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
Copy to Clipboard Toggle word wrap

1
コンテナーまたは Pod が実行時に使用するユーザー ID を要求しない場合、有効な UID はこの Pod を作成する SCC よって異なります。制限付き SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。この制限付き SCC は、securityContext.runAsUser フィールドの使用できる値を制限し、これをデフォルトに設定するために MustRunAsRange ストラテジーを使用します。受付プラグインではこの範囲を指定しないため、現行プロジェクトで openshift.io/sa.scc.uid-range アノテーションを検索して範囲フィールドにデータを設定します。最終的にコンテナーの runAsUser は予測が困難な範囲の最初の値と等しい値になります。予測が困難であるのはすべてのプロジェクトにはそれぞれ異なる範囲が設定されるためです。詳細は、「Understanding Pre-allocated Values and Security Context Constraints (事前に割り当てられた値および SCC (Security Context Constraint) について)」を参照してください。

明示的な 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
Copy to Clipboard Toggle word wrap

1
特定のユーザー ID を要求するコンテナーまたは Pod が OpenShift Container Platform によって受け入れられるのは、サービスアカウントまたはユーザーにそのユーザー ID を許可する SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。

これは SELinux、fsGroup、および補助グループで機能します。詳細は、「Volume Security」を参照してください。

15.7. デフォルト SCC (Security Context Constraints) の更新
リンクのコピー

デフォルト SCC は、それらが見つからない場合にはマスターの起動時に作成されます。SCC をデフォルトにリセットするか、またはアップグレード後に既存の SCC を新規のデフォルト定義に更新するには、以下を実行します。

  1. リセットする SCC を削除し、マスターを再起動してその再作成を実行します。
  2. oc adm policy reconcile-sccs コマンドを使用します。

oc adm policy reconcile-sccs コマンドは、すべての SCC ポリシーをデフォルト値に設定しますが、すでに設定した可能性のある追加ユーザー、グループ、ラベル、アノテーションおよび優先順位を保持します。変更される SCC を表示するには、オプションなしでコマンドを実行するか、または -o <format> オプションで優先する出力を指定してコマンドを実行します。

確認後は、既存 SCC のバックアップを取ってから --confirm オプションを使用してデータを永続化します。

注記

優先順位や許可をリセットする場合は、--additive-only=false オプションを使用します。

注記

SCC に優先順位、ユーザー、グループ、ラベル、またはアノテーション以外のカスタマイズ設定がある場合、これらの設定は調整時に失われます。

15.8. 使用方法
リンクのコピー

以下では、SCC を使用する一般的なシナリオおよび手順について説明します。

15.8.1. 特権付き SCC のアクセス付与
リンクのコピー

管理者が管理者グループ外のユーザーまたはグループに対して 特権付き Pod を追加作成するためのアクセスを付与することが必要になることがあります。これを実行するには、以下を行います。

  1. SCC へのアクセスを付与するユーザーまたはグループを決定します。

    警告

    ユーザーへのアクセス付与は、ユーザーが Pod を直接作成する場合にのみ可能です。ほとんどの場合、システム自体がユーザーの代わりに作成する Pod については、関連するコントローラーの作動に使用される サービスアカウントにアクセスを付与する必要があります。ユーザーの代わりに Pod を作成するリソースの例として、Deployments、StatefulSets、DaemonSets などが含まれます。

  2. 以下を実行します。 

    $ oc adm policy add-scc-to-user <scc_name> <user_name>
$ oc adm policy add-scc-to-group <scc_name> <group_name>
    Copy to Clipboard Toggle word wrap

    たとえば、e2e-user の 特権付き SCC へのアクセスを許可するには、以下を実行します。 

    $ oc adm policy add-scc-to-user privileged e2e-user
    Copy to Clipboard Toggle word wrap
  3. 特権モードを要求するようにコンテナーの SecurityContext を変更します。

15.8.2. 特権付き SCC のサービスアカウントアクセスの付与
リンクのコピー

最初に、サービスアカウントを作成します。たとえば、サービスアカウント mysvcacct をプロジェクト myproject で作成するには、以下を実行します。 

$ oc create serviceaccount mysvcacct -n myproject
Copy to Clipboard Toggle word wrap

次に、サービスアカウントを特権付き SCC に追加します。 

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct
Copy to Clipboard Toggle word wrap

その後は、リソースがサービスアカウントの代わりに作成されていることを確認します。これを実行するには、spec.serviceAccountName フィールドをサービスアカウント名に設定します。サービスアカウント名を空のままにすると、デフォルトのサービスアカウントが使用されます。

次に、少なくとも 1 つの Pod のコンテナーがセキュリティーコンテキストで特権モードを要求していることを確認します。

15.8.3. Dokerfile の USER によるイメージ実行の有効化
リンクのコピー

特権付き SCC へのアクセスをすべての人に与えることなく、イメージが事前割り当て UID で強制的に実行されないようにクラスターのセキュリティーを緩和するには、以下を実行します。

  1. すべての認証されたユーザーに anyuid SCC へのアクセスを付与します。 

    $ oc adm policy add-scc-to-group anyuid system:authenticated
    Copy to Clipboard Toggle word wrap
警告

これにより、USER が Dockerfile に指定されていない場合は、イメージをルート ID で実行することができます。

15.8.4. ルートを要求するコンテナーイメージの有効化
リンクのコピー

一部のコンテナーイメージ (例: postgres および redis) には root アクセスが必要であり、ボリュームの保有方法についてのいくつかの予測が設定されています。これらのイメージについては、サービスアカウントを anyuid SCC に追加します。 

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct
Copy to Clipboard Toggle word wrap

15.8.5. レジストリーでの --mount-host の使用
リンクのコピー

PersistentVolume および PersistentVolumeClaim オブジェクトを使用する永続ストレージをレジストリーのデプロイメントに使用することが推奨されます。テストを実行中で、oc adm registry コマンドを --mount-host オプションと共に使用する必要がある場合には、まずレジストリーの新規サービスアカウントを作成し、これを特権付き SCC に追加する必要があります。詳細の説明については、『Administrator Guide』を参照してください。

15.8.6. 追加機能の提供
リンクのコピー

場合によっては、Docker が追加設定なしの機能として提供していない機能がイメージで必要になることがあります。この場合、Pod 仕様で追加機能を要求することができ、これは SCC に対して検証されます。

重要

これによりイメージを昇格された機能を使って実行できますが、これは必要な場合にのみ実行する必要があります。追加機能を有効にするためにデフォルトの restricted SCC を編集することはできません。

非 root ユーザーによって使用される場合、setcap コマンドを使用して、追加機能を要求するファイルに該当する機能が付与されていることを確認する必要もあります。たとえば、イメージの Dockerfile では、以下のようになります。 

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping
Copy to Clipboard Toggle word wrap

さらに機能が Docker のデフォルトとして提供されている場合には、これを要求するために Pod 仕様を変更する必要はありません。たとえば、NET_RAW がデフォルトで指定されており、機能がすでに ping で設定されている場合、ping を実行するのに特別な手順は必要ありません。

追加機能を提供するには、以下を実行します。

  1. 新規 SCC を作成します。
  2. allowedCapabilities フィールドを使用して許可された機能を追加します。
  3. Pod の作成時に、securityContext.capabilities.add フィールドで機能を要求します。

15.8.7. クラスターのデフォルト動作の変更
リンクのコピー

すべてのユーザーに対して anyuid SCC のアクセスを付与する場合、クラスターは以下のようになります。

  • UID を事前に割り当てない
  • コンテナーの任意ユーザーとしての実行を許可する
  • 特権付きコンテナーを禁止する 
 $ oc adm policy add-scc-to-group anyuid system:authenticated
Copy to Clipboard Toggle word wrap

UID を事前に割り当てないようにし、コンテナーが root で実行されないようにクラスターを変更するには、すべてのユーザーに対して nonroot SCC のアクセスを付与します。 

 $ oc adm policy add-scc-to-group nonroot system:authenticated
Copy to Clipboard Toggle word wrap
警告

クラスター全体に影響を与える変更を行う際には十分に注意してください。直前の例のようにすべての認証ユーザーに SCC を付与したり、制限付き SCC のようにすべてのユーザーに適用される SCC を変更する場合には、Web コンソールや統合 Docker レジストリーなどの Kubernetes および OpenShift Container Platform コンポーネントにも影響を与えます。これらの SCC に関する変更により、これらのコンポーネントの機能を停止する可能性があります。

代わりに、カスタム SCC を作成し、このターゲットを特定のユーザーまたはグループのみに指定します。これにより、潜在的な問題の影響を特定の影響を受けるユーザーまたはグループに制限し、重要なクラスターコンポーネントに影響が及ばないようにすることができます。

15.8.8. hostPath ボリュームプラグインの使用
リンクのコピー

privileged、hostaccess、または hostmount-anyuid などの特権付き SCC へのアクセスをすべての人に付与することなく、Pod で hostPath ボリュームプラグインを使用できるようにクラスターのセキュリティーを緩和するには、以下を実行します。

  1. hostpath という名前の新規 SCC を作成します。

  2. 新規 SCC の allowHostDirVolumePlugin パラメーターを true に設定します。 

    $ oc patch scc hostpath -p '{"allowHostDirVolumePlugin": true}'
    Copy to Clipboard Toggle word wrap

  3. この SCC へのアクセスをすべてのユーザーに付与します。 

    $ oc adm policy add-scc-to-group hostpath system:authenticated
    Copy to Clipboard Toggle word wrap

これで、hostPath ボリュームを要求するすべての Pod は hostpath SCC で許可されます。

15.8.9. 受付を使用した特定 SCC の初回使用
リンクのコピー

SCC の Priority フィールドを設定し、受付コントローラーで SCC の並び替え順序を制御することができます。並び替えについての詳細は、「SCC Prioritization」セクションを参照してください。

15.8.10. SCC のユーザー、グループまたはプロジェクトへの追加
リンクのコピー

SCC をユーザーまたはグループに追加する前に、まず scc-review オプションを使用してユーザーまたはグループが Pod を作成できるかどうかをチェックできます。詳細は、「Authorization」のトピックを参照してください。

SCC はプロジェクトに直接付与されません。代わりに、サービスアカウントを SCC に追加し、Pod にサービスアカウント名を指定するか、または指定されない場合は default サービスアカウントを使用して実行します。

SCC をユーザーに追加するには、以下を実行します。 

$ oc adm policy add-scc-to-user <scc_name> <user_name>
Copy to Clipboard Toggle word wrap

SCC をサービスアカウントに追加するには、以下を実行します。 

$ oc adm policy add-scc-to-user <scc_name> \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>
Copy to Clipboard Toggle word wrap

現在の場所がサービスアカウントが属するプロジェクトの場合、-z フラグを使用し、<serviceaccount_name> のみを指定することができます。 

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>
Copy to Clipboard Toggle word wrap
重要

上記の -z フラグについては、誤字を防ぎ、アクセスが指定されたサービスアカウントのみに付与されるため、その使用をを強く推奨します。プロジェクトにいない場合は、-n オプションを使用して、それが適用されるプロジェクトの namespace を指定します。

SCC をグループに追加するには、以下を実行します。 

$ oc adm policy add-scc-to-group <scc_name> <group_name>
Copy to Clipboard Toggle word wrap

SCC を namespace のすべてのサービスアカウントに追加するには、以下を実行します。 

$ oc adm policy add-scc-to-group <scc_name> \
    system:serviceaccounts:<serviceaccount_namespace>
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat