前言：
安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：
- 自主访问控制（Discretionary Access Control）： 基于用户 ID（UID）和组 ID（GID） 来判定对对象（例如文件）的访问权限。
- 安全性增强的 Linux（SELinux）： 为对象赋予安全性标签。
- 以特权模式或者非特权模式运行。
- Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。
- AppArmor：使用程序配置来限制个别程序的权能。
- Seccomp：过滤进程的系统调用。
allowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置 no_new_privs标志。 当容器满足一下条件之一时，allowPrivilegeEscalation总是为 true（一般是false的）：
- 以特权模式运行，或者
- 具有
CAP_SYS_ADMIN权能
- readOnlyRootFilesystem：以只读方式加载容器的根文件系统（一般是true的，true时，exec进容器不能更改文件系统，例如，在容器内touch文件，删除文件，新建文件夹等等操作都会被禁止）
一，
安全上下文的示例
没有配置安全上下文的pod：
[root@k8s-master ~]# cat nosecurity_pod.yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: name: busybox-nosecurity spec: volumes: - name: sec-ctx-vol emptyDir: {} containers: - image: busybox name: busybox-nosecurity command: [ "sh","-c","sleep 1h" ] volumeMounts: - name: sec-ctx-vol mountPath: /data/demo dnsPolicy: ClusterFirst restartPolicy: Always status: {}
配置了安全上下文的pod：
cat security_pod.yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: name: busybox-security spec: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: - name: sec-ctx-vol emptyDir: {} containers: - image: busybox name: busybox-security command: [ "sh","-c","sleep 1h" ] volumeMounts: - name: sec-ctx-vol mountPath: /data/demo2 resources: {} securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true dnsPolicy: ClusterFirst restartPolicy: Always status: {}
若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置在与 Pod 层面设置的内容发生重叠时，会重写 Pod 层面的设置。Container 层面的设置不会影响到 Pod 的卷。说人话就是pod和容器两个层面都可以设置securitycontext，如果是多容器，比如，某个pod内有A和B两个容器，pod和容器B分别设置了securitycontext，那么，A容器使用pod的securitycontext，B容器使用它自己设置的securitycontext（这一段比较绕口，是需要仔细阅读理解的哦）
上面这个示例就仅仅设置了pod的securitycontext，但容器是继承了pod的securitycontext
进入没有配置安全上下文的pod：
可以看到是使用的root权限，可以任意做手脚
[root@k8s-master ~]# kubectl exec -it busybox-nosecurity -- /bin/sh / # id uid=0(root) gid=0(root) groups=10(wheel) / # / # ps PID USER TIME COMMAND 1 root 0:00 sleep 1h 28 root 0:00 /bin/sh 35 root 0:00 ps / # rm -rf .dockerenv bin/ data/ dev/ etc/ proc/ root/ sys/ tmp/ usr/ var/ / # rm -rf .dockerenv / #
进入配置了安全上下文的容器
可以看到无法使用root权限，安全性大大的提高了
[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh / $ id uid=1000 gid=3000 groups=2000 / $ ps PID USER TIME COMMAND 1 1000 0:00 sleep 1h 25 1000 0:00 /bin/sh 33 1000 0:00 ps / $ rm -rf home/ rm: can't remove 'home': Read-only file system / $ ls -al /data/demo2/ total 0 drwxrwsrwx 2 root 2000 6 Jan 8 20:00 . drwxr-xr-x 3 root root 19 Jan 8 20:00 .. / $ touch aaa touch: aaa: Read-only file system
二，
精细化的安全上下文权限分配 capabilities
默认情况下 Docker 会删除必须的 capabilities 之外的所有 capabilities，因为在容器中我们经常会以 root 用户来运行，使用 capabilities 后，容器中的使用的 root 用户权限就比我们平时在宿主机上使用的 root 用户权限要少很多了，这样即使出现了安全漏洞，也很难破坏或者获取宿主机的 root 权限，所以 Docker 支持 Capabilities 对于容器的安全性来说是非常有必要的，当然，kubernetes的底层是docker，所以kubernetes也是支持capabilities的
在说到这个capabilities之前，需要说一下特权容器，一般的容器是无法获取宿主机的内核参数的，但某些情况下，有和宿主机的内核交互的需求，容器中有些应用程序可能需要访问宿主机设备、修改内核等需求，在默认情况下， 容器没这个有这个能力，这个时候，就需要特权容器了，但这个特权容器是非常不安全的：
containers: - image: lizhenliang/flask-demo:root name: web securityContext: privileged: true
启用特权模式就意味着为容器提供了访问Linux内核的所有能力，这是很危险的，为了减少系统调用的供给，可以使用Capabilities为容器赋予仅所需的能力。
这个capabilities不是特别常见，coredns的部署里可以看到：
securityContext: allowPrivilegeEscalation: false capabilities: add: - NET_BIND_SERVICE drop: - all readOnlyRootFilesystem: true
具体的capabilities有哪些呢？capabilities(7) - Linux manual page 这个网站有比较详细的介绍，下图是一个简略的介绍：
例如下面这个示例，容器虽然是root用户，但只给了一个无关紧要的kill 进程权限，因此，这个pod是无法ping其它的pod的
cat security_pod.yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: name: busybox-security spec: volumes: - name: sec-ctx-vol emptyDir: {} containers: - image: busybox name: busybox-security command: [ "sh","-c","sleep 1h" ] volumeMounts: - name: sec-ctx-vol mountPath: /data/demo2 resources: {} securityContext: capabilities: drop: - ALL add: ["KILL"] allowPrivilegeEscalation: false readOnlyRootFilesystem: true dnsPolicy: ClusterFirst restartPolicy: Always status: {}
进入容器后，虽然是root用户，但是是无法执行需要高网络权限的命令的（ping命令需要网络权限）
[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh / # id uid=0(root) gid=0(root) groups=10(wheel) / # ping 10.244.0.13 PING 10.244.0.13 (10.244.0.13): 56 data bytes ping: permission denied (are you root?)
上述文件修改成如下：
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: name: busybox-security spec: volumes: - name: sec-ctx-vol emptyDir: {} containers: - image: busybox name: busybox-security command: [ "sh","-c","sleep 1h" ] volumeMounts: - name: sec-ctx-vol mountPath: /data/demo2 resources: {} securityContext: capabilities: drop: - ALL add: ["NET_ADMIN","NET_RAW"] allowPrivilegeEscalation: false readOnlyRootFilesystem: true dnsPolicy: ClusterFirst restartPolicy: Always status: {}
执行此文件后，就可以愉快的在容器内使用ping命令了：
[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh / # id uid=0(root) gid=0(root) groups=10(wheel) / # ping 10.244.0.13 PING 10.244.0.13 (10.244.0.13): 56 data bytes 64 bytes from 10.244.0.13: seq=0 ttl=62 time=1.142 ms 64 bytes from 10.244.0.13: seq=1 ttl=62 time=0.889 ms ^C --- 10.244.0.13 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.889/1.015/1.142 ms
小结：
securitycontext是对于pod和容器的安全性提升有非常大帮助的一个选项，因此，如果没有测试的需求，最好还是启用securitycontext，并且禁用privileged特权容器，以免对宿主机造成破坏。
