openshift scc解析

　　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