13.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: null 5 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 が、OpenShift Dedicated によって受け入れられるのは、サービスアカウントまたはユーザーにそのユーザー ID を許可する SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。
この設定は、SELinux、fsGroup、および Supplemental Groups について有効です。
