SCC使用UserID，FsGroupID以及supplemental group ID和SELinux label等策略，通過校驗Pod定義的ID是否在有效範圍內來限制pod的許可權。如果校驗失敗，則Pod也會啟動失敗。SCC的策略值設定為RunAsAny表示pod擁有該策略下的所有許可權。否則只有pod的SCC設定與SCC策略匹配時才能通過認證。
SCC可能會給出所允許的策略的值的範圍(如Must RunAsRange)，如果pod中沒有指定對應策略的值，則預設使用該pod所在的project中的最小值。
一個自定義的SCC如下：
$ oc get project default -o yaml ... metadata: annotations: #當SCC策略非RunAsAny時提供預設值 openshift.io/sa.scc.mcs: s0:c1,c0 #在pod或SCC沒有定義SELinux時提供預設值 openshift.io/sa.scc.supplemental-groups: 1000000000/10000 #允許的group ID範圍。可以支援多個範圍，使用逗號分隔 openshift.io/sa.scc.uid-range: 1000000000/10000 #允許的user ID範圍，僅支援單個範圍 $ oc get scc my-custom-scc -o yaml ... fsGroup: type: MustRunAs #MustRunAs強制進行group ID校驗，併為容器提供預設group，本SCC的預設group ID為5000。如果SCC未定義該欄位，則預設使用1000000000。使用RunAsAny不會校驗有效範圍(允許所有group id) ranges: - min: 5000 max: 6000 runAsUser: type: MustRunAsRange #MustRybAsRange強制對user ID進行校驗，並提供預設UID。本SCC的預設UID為1000100000。如果SCC未定義該欄位，則預設使用1000000000。其他類似為MustRunAsNonRoot和RunAsAny。可以用於定義訪問目標儲存的ID uidRangeMin: 1000100000 uidRangeMax: 1000100999 seLinuxContext: # type: MustRunAs #設定為MustRunAs，容器使用建立時定義的SCC SELinux選項，或使用project的預設MCS。RunAsAny表示不對SELinux校驗 SELinuxOptions: user: <selinux-user-name> role: ... type: ... level: ... supplementalGroups: type: MustRunAs #同FSGroup ranges: - min: 5000 max: 6000
M/N表示M為起始ID，範圍為M~M+N-1
Supplemental groups ID用於控制訪問共享儲存，如NFS，Gluster FS，而fsGroup用於控制訪問塊儲存，如Ceph RBD，iSCSI。OpenShift容器中掛載的卷和目標儲存擁有相同的許可權。如目標儲存的UID為1234，groupID為5678，則mount到node和容器中的卷同樣擁有這些ID值。因此容器的程式需要匹配一個或兩個ID才能使用這些卷。pod中的supplementalGroups和fsGroup在系統層面是不作區分的，只是用於在pod層面區分不同的場景，pod在定義這類值後，會新增到器系統的supplemental groups中。
驗證：
SCC主要涉及User Strategy，SELinux Context Strategy，FSGroup Strategy以及Supplemental Groups Strategy四大策略。下面通過對hostpath掛載卷的訪問來驗證SCC的功能。
首先建立一個serviceaccount作為pod的授權物件
# cat new-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: name: new-sa
然後建立一個單獨的SCC，名稱為new-scc。後面會使用hostpath的捲進行驗證，因此設定allowHostDirVolumePlugin: true；所有的策略設定為RunAsAny，即不對pod的許可權進行校驗，如果pod沒有設定這些策略的值，則使用project中提供的預設值。為不影響當前環境，使用新建立的SCC進行驗證，內容如下:
# cat new-scc.yaml allowHostDirVolumePlugin: true allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegedContainer: false allowedCapabilities:
- '*' apiVersion: v1 defaultAddCapabilities: [] fsGroup: type: RunAsAny groups: - system:authenticated kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: for test scc name: new-scc priority: null readOnlyRootFilesystem: false
runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny supplementalGroups: type: RunAsAny volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret
使用如下命令建立serviceaccount，scc，並將建立的new-scc授權給給serviceaccount
# oc create -f new-sa.yaml # oc create -f new-scc.yaml # oadm policy add-scc-to-user new-scc system:serviceaccount:monitor:new-sa
建立一個deploymentconfig，為方便定位問題，使用了centos映象(centos映象功能比較全)。該deploymentconfig配置了新建立的serviceaccount，且Pod中沒有配置任何SCC限制。
apiVersion: v1 kind: DeploymentConfig metadata: name: centos namespace: monitor spec: replicas: 1 template: metadata: labels: busybox: 'true' spec: containers: - args: image: 'centos:v2' imagePullPolicy: IfNotPresent name: busybox securityContext: runAsUser: 1000 runAsGroup: 2000 #該特性在k8s 1.10之後才支援，本環境未支援，參見Support for RunAsGroup as a pod security context volumeMounts: - mountPath: /centos name: centos-volume securityContext: {} nodeSelector: kubernetes.io/hostname: test volumes: - hostPath: path: /home/testHostPath name: centos-volume serviceAccountName: new-sa triggers: - type: ConfigChange
host上/home/testHostPath的許可權如下：
# ls -Z drwxr-xr-x. root root unconfined_u:object_r:home_root_t:s0 testHostPath
直接建立該deploymentconfig(oc create -f centos.yaml)，通過oc describe pod可以看到該pod使用了設定的scc和serviceaccount
Annotations: openshift.io/scc=new-scc
...... Containers: busybox: ...... Mounts: /centos from centos-volume (rw) /var/run/secrets/kubernetes.io/serviceaccount from new-sa-token-q5rxk (ro)
進入容器,可以看到該資料夾已經掛載進去,但沒有任何許可權操作該資料夾
sh-4.2$ cd /centos sh-4.2$ ls ls: cannot open directory .: Permission denied
登陸該容器所在node節點，檢視該容器的SELinux設定如下，顯然建立的資料夾的SELinux與容器不匹配，將host上資料夾的SELinux設定為與容器相匹配。
# docker inspect c21736278d1a|grep "MountLabel" "MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c15,c10",
# chcon -Rt svirt_sandbox_file_t testHostPath/
解決完SELinux之後，檢視該容器對應程式(docker inspect $CONTAINERID |grep Pid)的資訊/proc/$PID/status(具體含義參見/proc/[pid]/status)。可以看到該容器使用的user id為1000，group id為0，supplemental groups為100023000。user id和supplemental groups(Groups)使用了所在project的預設值，group id(含fsgroup)則使用了0。
# cat /proc/23032/status ...... Uid: 1000 1000 1000 1000 Gid: 0 0 0 0 FDSize: 2048 Groups: 1000230000
......
# oc describe project monitor Name: monitor Created: 2 weeks ago Labels: <none> Annotations: openshift.io/description= openshift.io/display-name= openshift.io/sa.scc.mcs=s0:c15,c10 openshift.io/sa.scc.supplemental-groups=1000230000/10000 openshift.io/sa.scc.uid-range=1000230000/10000
到此為止，容器可以讀取groupid為0的資料夾，但掛載的testHostPath的DAC許可權為755，沒有給group id為0的使用者組寫許可權，因此需要設定DAC許可權。這樣容器就可以對該掛載的資料夾進行讀寫了。
# chmod 775 testHostPath/
- 下面以runAsUser為例驗證SCC對pod的限制。將值從RunAsAny修改為如下內容(oc edit scc new-scc)，即允許的user ID範圍為為[3000,4000]。
runAsUser: type: MustRunAsRange uidRangeMax: 4000 uidRangeMin: 3000
重新建立該deploymentconfig，出現如下錯誤，即user ID無效。說明SCC對pod中程式的user ID進行了限制，只有符合條件的程式才能執行(本例中pod使用了project的預設值)。其他策略如fsGroup，supplementalGroups，seLinuxContext也類似，只有pod的策略值(未設定則使用預設值)與SCC相匹配才能通過SCC認證。
Error creating: pods "centos-1-" is forbidden: unable to validate against any security context constraint: [provider restricted: .spec.containers[0].securityContext.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used securityContext.runAsUser: Invalid value: 1000: UID on container busybox does not match required range. Found 1000, required min: 3000 max: 4000]
- 緊接上述設定進行驗證，設定pod的User id=4000(配置檔案見下)。將host上的testHostPath許可權修改如下，此時pod受DAC限制將無法訪問掛載的/centos目錄(此時pod使用uid=4000，gid=0)
# cd /home
# chown -R 5000:6000 testHostPath/
# chmod 770 testHostPath/
從容器中可以看到掛載的目錄的DAC許可權與host一致，此時pod的group作為other group，無法執行讀寫操作。
$ ls -Z /drwxrwx---. 5000 6000 unconfined_u:object_r:container_file_t:s0 centos
...
下面使用supplementalGroups進行授權訪問，修改deploymentconfig內容如下，新增supplementalGroups的支援
apiVersion: v1 kind: DeploymentConfig metadata: name: centos namespace: monitor spec: replicas: 1 template: metadata: labels: busybox: 'true' spec: containers: - args: image: 'centos:v2' imagePullPolicy: IfNotPresent name: busybox securityContext: runAsUser: 4000 runAsGroup: 2000 volumeMounts: - mountPath: /centos name: centos-volume securityContext: supplementalGroups: [6000] nodeSelector: kubernetes.io/hostname: test volumes: - hostPath: path: /home/testHostPath name: centos-volume serviceAccountName: new-sa triggers: - type: ConfigChange
重新建立該deploymentconfig，進入容器，檢視id，可以發現supplementgroups新增了6000，這樣就可以在掛載卷中進行讀寫操作了。
$ id uid=4000 gid=0(root) groups=0(root),6000,1000230000
TIPS:
- 通常使用supplemental group ID或fsGroup作為訪問儲存的憑證
- SCC對應kubernetes的PodSecurityPolicy，其在v1.14中為beta版本
- 可以通過oc get pod <pod_name> -o yaml命令檢視pod使用的SCC，對應annotation的key為openshift.io/scc。
- openshift role和clusterrole用於控制pod服務對openshift資源的訪問；而SCC用於控制pod的啟動和對掛載卷的訪問
參考：
https://docs.openshift.com/container-platform/3.6/install_config/persistent_storage/pod_security_context.html
https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/authorization.html#roles