首先區分下下面兩個privileged的區別:
-
- 容器 privileged
- scc privileged
因為某些原因有些容器通常需要會以privileged權限運行，此時該容器擁有了node節點的root權限，可能會造成安全隱患。但大部分場景下容器其實並不需要這么大的權限(如僅使用節點掛載目錄的容器不需要有網絡權限)。scc就是為了防止這種情況發生的，它對容器權限又作了進一步的細化，可以看作是容器外圍的一個權限管控組件，這樣如果scc沒有授予相應的權限，即使給容器設置了privileged(類似docker run --privileged)它也無法真正獲得該權限。scc的privileged就相當於對容器不做任何限制，即該組件無效。參考
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的啟動和對掛載卷的訪問
- 注意：給openshift的默認serviceaccount添加privileged權限的命令是：oc adm policy add-scc-to-user privileged -z default，而不是oc adm policy add-scc-to-user privileged default。
參考：
- 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