openshift scc解析

概述　　SCC使用UserID，FsGroupID以及supplemental group ID和SELinux label等策略，通过校验Pod定义的ID是否在有效范围内来限制pod的权限。如果校验失败，则Pod也会启动失败。SCC的策略值设置为RunAsAny表示pod拥有该策略下的所有权限。否则只有pod的SCC设置与SCC策略匹配时才能通过认证。 　　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如下：

@H_403_13@$ 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: 6000runAsUser: type: MustRunAsRange #MustRybAsRange强制对user ID进行校验，并提供默认UID。本SCC的默认UID为1000100000。如果SCC未定义该字段，则默认使用1000000000。其他类似为MustRunAsNonRoot和RunAsAny。可以用于定义访问目标存储的ID uIDRangeMin: 1000100000 uIDRangeMax: 1000100999selinuxContext: # 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的授权对象

@H_403_13@# cat new-sa.yamlAPIVersion: v1kind: ServiceAccountMetadata: name: new-sa

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

@H_403_13@# cat new-scc.yamlallowHostDirVolumePlugin: trueallowHostIPC: falseallowHostNetwork: falseallowHostPID: falseallowHostPorts: falseallowPrivilegedContainer: falseallowedCapabilitIEs:
- ‘*‘APIVersion: v1defaultAddCapabilitIEs: []fsGroup: type: RunAsAnygroups:- system:authenticatedkind: SecurityContextConstraintsMetadata: annotations: kubernetes.io/description: for test scc name: new-sccpriority: nullReadonlyRootfilesystem: false
runAsUser: type: RunAsAnyselinuxContext: type: RunAsAnysupplementalGroups: type: RunAsAnyvolumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim- projected- secret

使用如下命令创建serviceaccount，scc，并将创建的new-scc授权给给serviceaccount

@H_403_13@# 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限制。

@H_403_13@APIVersion: v1kind: DeploymentConfigMetadata: name: centos namespace: monitorspec: 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的权限如下：

@H_403_13@# ls -Zdrwxr-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

@H_403_13@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)

进入容器,可以看到该文件夹已经挂载进去,但没有任何权限 *** 作该文件夹

@H_403_13@sh-4.2$ cd /centos sh-4.2$ ls ls: cannot open directory .: Permission denIEd

登陆该容器所在node节点，查看该容器的SElinux设置如下，显然创建的文件夹的SElinux与容器不匹配，将host上文件夹的SElinux设置为与容器相匹配。

@H_403_13@# docker inspect c21736278d1a|grep "MountLabel" "MountLabel": "system_u:object_r:svirt_sandBox_file_t:s0:c15,c10", @H_403_13@# 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。

@H_403_13@# cat /proc/23032/status......UID: 1000 1000 1000 1000GID: 0 0 0 0FDSize: 2048Groups: 1000230000
...... @H_403_13@# oc describe project monitorname: monitorCreated: 2 weeks agoLabels: <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权限。这样容器就可以对该挂载的文件夹进行读写了。

@H_403_13@# chmod 775 testHostPath/ 下面以runAsUser为例验证SCC对pod的限制。将值从RunAsAny修改为如下内容(oc edit scc new-scc)，即允许的user ID范围为为[3000,4000]。 @H_403_13@runAsUser: type: MustRunAsRange uIDRangeMax: 4000 uIDRangeMin: 3000

重新创建该deploymentconfig，出现如下错误，即user ID无效。说明SCC对pod中进程的user ID进行了限制，只有符合条件的进程才能执行(本例中pod使用了project的默认值)。其他策略如fsGroup，supplementalGroups，selinuxContext也类似，只有pod的策略值(未设置则使用默认值)与SCC相匹配才能通过SCC认证。

@H_403_13@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) @H_403_13@# cd /home
# chown -R 5000:6000 testHostPath/
# chmod 770 testHostPath/

从容器中可以看到挂载的目录的DAC权限与host一致，此时pod的group作为other group，无法执行读写 *** 作。

@H_403_13@$ ls -Z /drwxrwx---. 5000 6000 unconfined_u:object_r:container_file_t:s0 centos...

下面使用supplementalGroups进行授权访问，修改deploymentconfig内容如下，添加supplementalGroups的支持

@H_403_13@APIVersion: v1kind: DeploymentConfigMetadata: name: centos namespace: monitorspec: 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，这样就可以在挂载卷中进行读写 *** 作了。

@H_403_13@$ IDuID=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

总结

以上是内存溢出为你收集整理的openshift scc解析全部内容，希望文章能够帮你解决openshift scc解析所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。