openshift scc解析

时间 2019-12-08

标签 openshift scc 解析繁體版

原文原文链接

　　SCC使用UserID，FsGroupID以及supplemental group ID和SELinux label等策略，经过校验Pod定义的ID是否在有效范围内来限制pod的权限。若是校验失败，则Pod也会启动失败。SCC的策略值设置为RunAsAny表示pod拥有该策略下的全部权限。不然只有pod的SCC设置与SCC策略匹配时才能经过认证。html

　　SCC可能会给出所容许的策略的值的范围(如Must RunAsRange)，若是pod中没有指定对应策略的值，则默认使用该pod所在的project中的最小值。node

一个自定义的SCC以下：linux

$ 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-1docker

　　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中。centos

验证：api

SCC主要涉及User Strategy，SELinux Context Strategy，FSGroup Strategy以及Supplemental Groups Strategy四大策略。下面经过对hostpath挂载卷的访问来验证SCC的功能。ide

首先建立一个serviceaccount做为pod的受权对象ui

# cat new-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: new-sa

而后建立一个单独的SCC，名称为new-scc。后面会使用hostpath的卷进行验证，所以设置allowHostDirVolumePlugin: true；全部的策略设置为RunAsAny，即不对pod的权限进行校验，若是pod没有设置这些策略的值，则使用project中提供的默认值。为不影响当前环境，使用新建立的SCC进行验证，内容以下:spa

# 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受权给给serviceaccountrest

# 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

1. 2.openshift受权策略和scc理解
2. E. Reachability from the Capital 解析(思維、SCC)
3. Openshift
4. OpenShift——大杂烩
5. OpenShift安装
6. 详解openshift-sdn
7. openshift pod对外访问网络解析
8. sdut 2170 The Largest SCC
9. openshift
10. OpenShift实战(一)：OpenShift安装
更多相关文章...
• XML DOM 解析器 - XML DOM 教程
• TCP报文格式解析 - TCP/IP教程
• 互联网组织的未来：剖析GitHub员工的任性之源
• Scala 中文乱码解决