第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 を検査するには、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>
アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ、ラベル、およびアノテーション以外にはデフォルトの SCC の設定を編集しないでください。
15.4. 新規 SCC (Security Context Constraints) の作成
新規 SCC を作成するには、以下を実行します。
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 をKILL
、MKNOD
、およびSYS_CHROOT
の必要なドロップ機能を使って作成するには、以下を SCC オブジェクトに追加します。requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT
使用できる値の一覧は、Docker ドキュメントで確認できます。
ヒント機能は Docker に渡されるため、特殊な
ALL
値を使用してすべての機能をドロップすることができます。次に、作成するファイルを渡して
oc create
を実行します。$ 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]
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、および補助グループで機能します。詳細は、「Volume Security」を参照してください。
15.7. デフォルト SCC (Security Context Constraints) の更新
デフォルト SCC は、それらが見つからない場合にはマスターの起動時に作成されます。SCC をデフォルトにリセットするか、またはアップグレード後に既存の SCC を新規のデフォルト定義に更新するには、以下を実行します。
- リセットする SCC を削除し、マスターを再起動してその再作成を実行します。
-
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 を追加作成するためのアクセスを付与することが必要になることがあります。これを実行するには、以下を行います。
SCC へのアクセスを付与するユーザーまたはグループを決定します。
警告ユーザーへのアクセス付与は、ユーザーが Pod を直接作成する場合にのみ可能です。ほとんどの場合、システム自体がユーザーの代わりに作成する Pod については、関連するコントローラーの作動に使用される サービスアカウントにアクセスを付与する必要があります。ユーザーの代わりに Pod を作成するリソースの例として、Deployments、StatefulSets、DaemonSets などが含まれます。
以下を実行します。
$ 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
-
特権モードを要求するようにコンテナーの
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 で強制的に実行されないようにクラスターのセキュリティーを緩和するには、以下を実行します。
すべての認証されたユーザーに anyuid SCC へのアクセスを付与します。
$ oc adm policy add-scc-to-group anyuid system:authenticated
これにより、USER が Dockerfile に指定されていない場合は、イメージをルート 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
を実行するのに特別な手順は必要ありません。
追加機能を提供するには、以下を実行します。
- 新規 SCC を作成します。
-
allowedCapabilities
フィールドを使用して許可された機能を追加します。 -
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 コンソールや統合 Docker レジストリーなどの Kubernetes および OpenShift Container Platform コンポーネントにも影響を与えます。これらの SCC に関する変更により、これらのコンポーネントの機能を停止する可能性があります。
代わりに、カスタム SCC を作成し、このターゲットを特定のユーザーまたはグループのみに指定します。これにより、潜在的な問題の影響を特定の影響を受けるユーザーまたはグループに制限し、重要なクラスターコンポーネントに影響が及ばないようにすることができます。
15.8.8. hostPath ボリュームプラグインの使用
privileged、hostaccess、または hostmount-anyuid などの特権付き SCC へのアクセスをすべての人に付与することなく、Pod で hostPath
ボリュームプラグインを使用できるようにクラスターのセキュリティーを緩和するには、以下を実行します。
-
hostpath
という名前の新規 SCC を作成します。 新規 SCC の
allowHostDirVolumePlugin
パラメーターをtrue
に設定します。$ oc patch scc hostpath -p '{"allowHostDirVolumePlugin": true}'
この 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>