简介
因为有时候对 ServiceAccount(SA)、SecurityContextConstriant (SCC)、securityContext(SC) 有些混乱，所以感觉有必要做下实验加深下理解，不少初学者在运行应用的时候都遇到的关于SA和SCC的问题。我将先部署一个简单的应用作为测试环境。我使用的是openshift 3.9
部署应用
我使用的是busybox，一个轻量级的工具镜像，尤其在测试网络连通性的时候非常有用。
使用镜像进行部署
oc new-app --docker-image=docker.io/busybox --name=busybox923
修改DC yaml文件的启动命令，因为busybox默认是以bash启动，会一直重启，我将它改为sleep
spec: containers: - image: 'docker.io/busybox:latest' command: - sleep - 30d
查看pod状态已经正常运行了
# oc get pod
NAME READY STATUS RESTARTS AGE busybox923-3-qk7hj 1/1 Running 0 17m
分析现在busybox相关内容
查看busybox的DC yaml文件，截取相关内容
# oc get dc/busybox923 -o yaml
apiVersion: apps.openshift.io/v1 kind: DeploymentConfig ... spec: ... template: metadata: annotations: openshift.io/generated-by: OpenShiftNewApp creationTimestamp: null labels: app: busybox923 deploymentconfig: busybox923 spec: containers: - command: - sleep - 30d image: docker.io/busybox:latest imagePullPolicy: IfNotPresent name: busybox923 resources: {} terminationMessagePath: dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst ...
查看busybox的pod yaml文件，截取相关内容
# oc get pod busybox923-3-qk7hj -o yaml
apiVersion: v1 kind: Pod ···· name: busybox923-3-qk7hj namespace: default··· spec: containers: - command: - sleep - 30d image: docker.io/busybox:latest imagePullPolicy: IfNotPresent name: busybox923 resources: {} securityContext: capabilities: drop: - KILL - MKNOD - SETGID - SETUID runAsUser: 1000000000··· securityContext: fsGroup: 1000000000 seLinuxOptions: level: s0:c1,c0 serviceAccount: default serviceAccountName: default···
查看pod运行的用户
# oc rsh busybox923-3-qk7hj
/ $ whoami
whoami: unknown uid 1000000000
分析：可以看到DC关于是没有定于关于sa与sc的配置，而pod则定义了使用default的serviceAccount，并在securityContext定义了runAsUser: 1000000000（查看container字段的securityContext，并且进入busybox的pod看到的用户id为1000000000，这些都是openshift的默认参数，这个时候在容器以非root权限启动时去访问须有root权限时容易报错。
试着在DC内添加runAsUser: 1000000000为0，0即root
# oc get pod
NAME READY STATUS RESTARTS AGE busybox923-5-bm5t7 1/1 Running 0 1m busybox923-6-deploy 1/1 Running 0 22s
一直无法生产新的pod，即版本6的pod，查看下deploy pod的日志
# oc log busybox923-6-deploy
W1026 10:12:37.477358 36823 cmd.go:358] log is DEPRECATED and will be removed in a future version. Use logs instead. --> Scaling up busybox923-6 from 0 to 1, scaling down busybox923-5 from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling busybox923-6 up to 1
因此将DC给runAsUser给删了就可以了
# oc get pod
NAME READY STATUS RESTARTS AGE busybox923-5-bm5t7 1/1 Terminating 0 4m busybox923-6-deploy 0/1 Terminating 0 3m busybox923-7-deploy 1/1 Running 0 9s busybox923-7-qtnvn 1/1 Running 0 5s
SA、SCC、SC介绍及使用
SA是用来定义 pod 启动时的用户，注意这个用户不是指 pod 容器里头的Linux用户，只是这个pod能干什么的用户；SCC就是具体的权限角色了，需要将SCC的角色分配给SA用户，系统默认就定义好了很多SCC，我们直接拿来用就可以了；而SC就是分配好，管理员再在pod定义具体使用那些权限的。
查看系统默认的SCC，常用的是privileged，它能够以root用户运行，并且访问宿主机上的文件系统
# oc get scc
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret] hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret] hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*] restricted false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
我部署的应用是在default这个project下面，每个项目都有default这个sa，注意在页面上是看不到default这个sa的。
# oc get sa
NAME SECRETS AGE builder 2 131d
default 3 131d deployer 2 131d registry 3 131d router 2 131d
现在我给default这个sa分配privileged的权限
# oc adm policy add-scc-to-user privileged -z default
scc "privileged" added to: ["system:serviceaccount:default:default"]
把pod杀了，让它自动新建一个，登录进pod的uid还是不变，并且dc和pod的yaml文件关于sa和sc字段还是不变。
在dc的container字段内添加sc配置 privileged: true
containers: - command: - sleep - 30d image: docker.io/busybox:latest imagePullPolicy: IfNotPresent name: busybox923 resources: {} securityContext: capabilities: {} privileged: true
查看pod的yaml文件，默认定义在securityContext字段的参数变了
spec: containers: - command: - sleep - 30d image: docker.io/busybox:latest imagePullPolicy: IfNotPresent name: busybox923 resources: {} securityContext: capabilities: {} privileged: true terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: default-token-xthkz readOnly: true dnsPolicy: ClusterFirst imagePullSecrets: - name: default-dockercfg-6h8bz nodeName: local2-ocp3.9-node1-test.com restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default
查看pod运行的用户，这时候为root了
# oc rsh busybox923-8-59hvm
/ # whoami
root
试着将privileged: true参数定义在外面的securityContext，而不是container字段内定义，试了一下不会生效，还是为securityContext: {}；接下来的测试都不在外面的securityContext测试了，默认都在container字段内测试。
将privileged: true修改为自定义的用户id，如：runAsUser: 123，忽然发现使用id命令也能看到当前用户属于哪个组，可以看到属于root组。
# oc rsh busybox923-10-p69mg
/ $ whoami
whoami: unknown uid 123
/ $ id uid=123 gid=0(root)
将securityContext全部删除，测试下是id命令的结果，多了个groups。
# oc rsh busybox923-11-tblhh
/ $ id
uid=1000000000 gid=0(root) groups=1000000000
配置securityContext的runAsUser为0，查看pod的用户id 为root
# oc rsh busybox923-12-cq5qt
/ # id
uid=0(root) gid=0(root) groups=10(wheel)
测试未在DC的yaml文件中配置 privileged: true 权限下挂载宿主机的docker可执行文件及docker配置文件
spec: containers: - command: - sleep - 30d ... volumeMounts: - mountPath: /usr/bin/docker name: docker - mountPath: /etc/sysconfig/docker name: docker-config ... securityContext: {} ... volumes: - hostPath: path: /usr/bin/docker type: '' name: docker - hostPath: path: /etc/sysconfig/docker type: '' name: docker-config
进入pod，可以看到是root用户，并且docker文件已经挂载进来了
# oc rsh busybox923-17-vb94f
/ # id
/ # ls -l etc/sysconfig/docker
-rw-r--r-- 1 root root 1243 Mar 19 2018 etc/sysconfig/docker uid=0(root) gid=0(root) groups=10(wheel) / # ls -l usr/bin/docker
-rwxr-xr-x 1 root root 735 Mar 19 2018 usr/bin/docker
我也看了dc及pod的yaml文件，都没有关于sc的定义，所以应该是在使用宿主机volume的时候就开启了privileged： true
给sa分配scc为privileged权限很大了，在有些时候只需要分配让pod以root用户启动即可，即修改privileged为anyuid
oc adm policy remove-scc-from-user privileged -z default
oc adm policy add-scc-to-user anyuid -z default
这时候删除pod，不会启动新的pod，怀疑目前因为挂载的宿主机的volume，并且因为scc权限低，所以pod无法创建，所以在dc内删除volume相关的配置，触发新的部署，新pod就被创建了，我再次将volume的配置添加进dc，查看一下，虽然新的部署被触发，但是新的pod没有被创建，说明在没有足够大的权限下，pod无法创建。
[root@local2-ocp3.9-master1-test.com ~]# oc get pod
NAME READY STATUS RESTARTS AGE busybox923-21-cktj5 1/1 Running 0 2m busybox923-22-deploy 1/1 Running 0 10s
再次将volume相关配置删除，触发新的部署，进入pod看下用户为root
# oc rsh busybox923-23-nmk7h
/ # id
uid=0(root) gid=0(root) groups=10(wheel) / # whoami
root
创建新的sa，并且使用它
前面pod启动时，使用的是project 默认的default sa，我们可以自己新建一个作为测试
# oc create sa busybox
serviceaccount "busybox" created
在DC内定义使用busybox这个sa去启动
serviceAccount: busybox serviceAccountName: busybox
进入pod，用户跟sa 为 default时没差
# oc rsh busybox923-24-l5szd
/ $ id uid=1000000000 gid=0(root) groups=1000000000
/ $ whoami
whoami: unknown uid 1000000000
给busybox分配scc为anyuid进行测试，用户为root
# oc adm policy add-scc-to-user anyuid -z busybox
scc "anyuid" added to: ["system:serviceaccount:default:busybox"]
# oc rsh busybox923-24-fjkrb
/ # id
uid=0(root) gid=0(root) groups=10(wheel) / # whoami
root
总结
以上只是对sa、scc、sc常用的一些配置使用做了测试和介绍，更深入和灵活的用法还需在具体环境及需求中进行测试验证，openshift/kubernetes是很强大很复杂的一个系统，还需多深入研究。
