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 (ボリュームセキュリティー) を参照してください。
