Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第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]

15.3. SCC (Security Context Constraints) オブジェクトの検査

特定の SCC についての情報(SCC が適用されるユーザー、サービスアカウントおよびグループを含む)を表示できます。

たとえば、制限付き SCC を検査するには、以下を実行します。

$ oc describe scc restricted
Name:					restricted
Priority:				<none>
Access:
  Users:				<none> 1
  Groups:				system:authenticated 2
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>
1
SCC が適用されているユーザーとサービスアカウントを一覧表示します。
2
SCC が適用されるグループを一覧表示します。
注記

アップグレード時にカスタマイズされた 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

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

    requiredDropCapabilities:
    - KILL
    - MKNOD
    - SYS_CHROOT

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

    ヒント

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

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

    $ oc create -f scc_admin.yaml
    securitycontextconstraints "scc-admin" created
  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 glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]

15.5. SCC (Security Context Constraints) の削除

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

$ oc delete scc <scc_name>
注記

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

15.6. SCC (Security Context Constraints) の更新

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

$ oc edit scc <scc_name>
注記

アップグレード時にカスタマイズされた 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

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

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

これは SELinux、fsGroup、および Supplemental Groups で機能します。詳細は、「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>

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

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

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

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

$ oc create serviceaccount mysvcacct -n myproject

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

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct

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

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

15.8.3. Dokerfile の USER によるイメージ実行の有効化

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

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

    $ oc adm policy add-scc-to-group anyuid system:authenticated
警告

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

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

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

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct

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

さらに機能が 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

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

 $ oc adm policy add-scc-to-group nonroot system:authenticated
警告

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

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

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

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

  1. hostpath という名前の新規 SCC を作成します。
  2. 新規 SCC の allowHostDirVolumePlugin パラメーターを true に設定します。

    $ oc patch scc hostpath -p '{"allowHostDirVolumePlugin": true}'
  3. この SCC へのアクセスをすべてのユーザーに付与します。

    $ oc adm policy add-scc-to-group hostpath system:authenticated

これで、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>

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

$ oc adm policy add-scc-to-user <scc_name> \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>

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

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>
重要

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

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

$ oc adm policy add-scc-to-group <scc_name> <group_name>

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

$ oc adm policy add-scc-to-group <scc_name> \
    system:serviceaccounts:<serviceaccount_namespace>