Kubernetes的安全上下文是传递给容器运行时的参数，能够在运行时配置Pod和容器的安全性。要为Pod设置安全性设置，可以在Pod规约中包含securityContext字段。这个字段的值是一个PodSecurityContext对象，通过这种方式，可以为Pod设定所需的安全性配配置。
安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：
1、自主访问控制（Discretionary Access Control）： 基于用户 ID（UID）和组 ID（GID） 来判定对对象（例如文件）的访问权限。
2；安全性增强的 Linux（SELinux）： 为对象赋予安全性标签。
3、以特权模式或者非特权模式运行。
4、Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。
5、AppArmor：使用程序配置来限制个别程序的权能。
6、Seccomp：过滤进程的系统调用。
7、allowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置 no_new_privs标志。 当容器满足一下条件之一时，allowPrivilegeEscalation 总是为 true：
- 以特权模式运行；
- 具有 CAP_SYS_ADMIN 权能。
8、readOnlyRootFilesystem：以只读方式加载容器的根文件系统。
一、准备
首先必须拥有一个 Kubernetes 的集群，同时必须配置 kubectl 命令行工具与集群通信。 建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。 如果还没有集群，可以通过 Minikube 构建一个自己的集群，或者可以使用下面的 Kubernetes 练习环境之一：
- Killercoda
- 玩转 Kubernetes
要获知版本信息，请输入 kubectl version.
二、Pod安全性上下文
要为 Pod 设置安全性设置，可在 Pod 规约中包含 securityContext 字段。securityContext 字段值是一个 PodSecurityContext 对象。为 Pod 所设置的安全性配置会应用到 Pod 中所有 Container 上。 下面是一个 Pod 的配置文件，该 Pod 定义了 securityContext 和一个 emptyDir 卷：
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
在配置文件中，runAsUser 字段指定 Pod 中的所有容器内的进程都使用用户 ID 1000 来运行。runAsGroup 字段指定所有容器中的进程都以主组 ID 3000 来运行。 如果忽略此字段，则容器的主组 ID 将是 root（0）。 当 runAsGroup 被设置时，所有创建的文件也会划归用户 1000 和组 3000。 由于 fsGroup 被设置，容器中所有进程也会是附组 ID 2000 的一部分。 卷 /data/demo 及在该卷中创建的任何文件的属主都会是组 ID 2000。
创建该 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
检查 Pod 的容器处于运行状态：
kubectl get pod security-context-demo
开启一个 Shell 进入到运行中的容器：
kubectl exec -it security-context-demo -- sh
在 Shell 中，列举运行中的进程：
ps
输出显示进程以用户 1000 运行，即 runAsUser 所设置的值：
PID USER TIME COMMAND 1 1000 0:00 sleep 1h 6 1000 0:00 sh ...
在 Shell 中，进入 /data 目录列举其内容：
cd /data ls -l
输出显示 /data/demo 目录的组 ID 为 2000，即 fsGroup 的设置值：
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
在 Shell 中，进入到 /data/demo 目录下创建一个文件：
cd demo echo hello > testfile
列举 /data/demo 目录下的文件：
ls -l
输出显示 testfile 的组 ID 为 2000，也就是 fsGroup 所设置的值：
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
运行下面的命令：
id
输出类似于：
uid=1000 gid=3000 groups=2000
从输出中会看到 gid 值为 3000，也就是 runAsGroup 字段的值。 如果 runAsGroup 被忽略，则 gid 会取值 0（root），而进程就能够与 root 用户组所拥有以及要求 root 用户组访问权限的文件交互。
退出 Shell：
exit
三、配置卷访问权限/属主变更策略
默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限， 使之与 Pod 的 securityContext 中指定的 fsGroup 匹配。 对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。 可以在 securityContext 中使用 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷属主和访问权限的方式。
fsGroupChangePolicy – fsGroupChangePolicy 定义在卷被暴露给 Pod 内部之前对其 内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 fsGroup 来 控制属主与访问权限的卷类型。此字段的取值可以是：
- OnRootMismatch：只有根目录的属主与访问权限与卷所期望的权限不一致时， 才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问 权限所需要的时间；
- Always：在挂载卷时总是更改卷中内容的属主和访问权限。
例如：
securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 fsGroupChangePolicy: "OnRootMismatch"
注意：此字段对于 secret、 configMap 和 emptydir 这类临时性存储无效。
四、更改委派给CSI驱动程序
如果部署了一个容器存储接口 (CSI) 驱动，而该驱动支持 VOLUME_MOUNT_GROUP NodeServiceCapability， 在 securityContext 中指定 fsGroup 来设置文件所有权和权限的过程将由 CSI 驱动而不是 Kubernetes 来执行。在这种情况下，由于 Kubernetes 不执行任何所有权和权限更改， fsGroupChangePolicy 不会生效，并且按照 CSI 的规定，CSI 驱动应该使用所指定的 fsGroup 来挂载卷，从而生成了一个对 fsGroup 可读/可写的卷.
五、Container安全性上下文
若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置在与 Pod 层面设置的内容发生重叠时，会重写 Pod 层面的设置。Container 层面的设置不会影响到 Pod 的卷。
下面是一个 Pod 的配置文件，其中包含一个 Container。Pod 和 Container 都有 securityContext 字段：
apiVersion: v1 kind: Pod metadata: name: security-context-demo-2 spec: securityContext: runAsUser: 1000 containers: - name: sec-ctx-demo-2 image: gcr.io/google-samples/node-hello:1.0 securityContext: runAsUser: 2000 allowPrivilegeEscalation: false
创建该 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
验证 Pod 中的容器处于运行状态：
kubectl get pod security-context-demo-2
启动一个 Shell 进入到运行中的容器内：
kubectl exec -it security-context-demo-2 -- sh
在 Shell 中，列举运行中的进程：
ps aux
输出显示进程以用户 2000 运行。该值是在 Container 的 runAsUser 中设置的。 该设置值重写了 Pod 层面所设置的值 1000。
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 2000 1 0.0 0.0 4336 764 ? Ss 20:36 0:00 /bin/sh -c node server.js 2000 8 0.1 0.5 772124 22604 ? Sl 20:36 0:00 node server.js ...
退出 Shell：
exit
六、Container设置权能
使用 Linux 权能， 可以赋予进程 root 用户所拥有的某些特权，但不必赋予其全部特权。 要为 Container 添加或移除 Linux 权能，可以在 Container 清单的 securityContext 节包含 capabilities 字段。
首先，看一下不包含 capabilities 字段时候会发生什么。 下面是一个配置文件，其中没有添加或移除容器的权能：
apiVersion: v1 kind: Pod metadata: name: security-context-demo-3 spec: containers: - name: sec-ctx-3 image: gcr.io/google-samples/node-hello:1.0
创建该 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
验证 Pod 的容器处于运行状态：
kubectl get pod security-context-demo-3
启动一个 Shell 进入到运行中的容器：
kubectl exec -it security-context-demo-3 -- sh
在 Shell 中，列举运行中的进程：
ps aux
输出显示容器中进程 ID（PIDs）：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 4336 796 ? Ss 18:17 0:00 /bin/sh -c node server.js root 5 0.1 0.5 772124 22700 ? Sl 18:17 0:00 node server.js
在 Shell 中，查看进程 1 的状态：
cd /proc/1 cat status
输出显示进程的权能位图：
... CapPrm: 00000000a80425fb CapEff: 00000000a80425fb ...
记下进程权能位图，之后退出 Shell：
exit
接下来运行一个与前例中容器相同的容器，只是这个容器有一些额外的权能设置。
下面是一个 Pod 的配置，其中运行一个容器。配置为容器添加 CAP_NET_ADMIN 和 CAP_SYS_TIME 权能：
apiVersion: v1 kind: Pod metadata: name: security-context-demo-4 spec: containers: - name: sec-ctx-4 image: gcr.io/google-samples/node-hello:1.0 securityContext: capabilities: add: ["NET_ADMIN", "SYS_TIME"]
创建 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
启动一个 Shell，进入到运行中的容器：
kubectl exec -it security-context-demo-4 -- sh
在 Shell 中，查看进程 1 的权能：
cd /proc/1 cat status
输出显示的是进程的权能位图：
... CapPrm: 00000000aa0435fb CapEff: 00000000aa0435fb ...
比较两个容器的权能位图：
00000000a80425fb 00000000aa0435fb
在第一个容器的权能位图中，位 12 和 25 是没有设置的。在第二个容器中，位 12 和 25 是设置了的。位 12 是 CAP_NET_ADMIN 而位 25 则是 CAP_SYS_TIME。
说明： Linux 权能常数定义的形式为 CAP_XXX。但是在 container 清单中列举权能时， 要将权能名称中的 CAP_ 部分去掉。例如，要添加 CAP_SYS_TIME， 可在权能列表中添加 SYS_TIME。
七、容器Seccomp配置
若要为容器设置 Seccomp 配置（Profile），可在 Pod 或 Container 清单的 securityContext 节中包含 seccompProfile 字段。该字段是一个 SeccompProfile 对象，包含 type 和 localhostProfile 属性。 type 的合法选项包括 RuntimeDefault、Unconfined 和 Localhost。 localhostProfile 只能在 type: Localhost 配置下才可以设置。 该字段标明节点上预先设定的配置的路径，路径是相对于 kubelet 所配置的 Seccomp 配置路径（使用 –root-dir 设置）而言的。
下面是一个例子，设置容器使用节点上容器运行时的默认配置作为 Seccomp 配置：
... securityContext: seccompProfile: type: RuntimeDefault
下面是另一个例子，将 Seccomp 的样板设置为位于 <kubelet-根目录>/seccomp/my-profiles/profile-allow.json 的一个预先配置的文件。
... securityContext: seccompProfile: type: Localhost localhostProfile: my-profiles/profile-allow.json
八、Container SELinux标签
若要给 Container 设置 SELinux 标签，可以在 Pod 或 Container 清单的 securityContext 节包含 seLinuxOptions 字段。 seLinuxOptions 字段的取值是一个 SELinuxOptions 对象。下面是一个应用 SELinux 标签的例子：
... securityContext: seLinuxOptions: level: "s0:c123,c456"
注意：要指定 SELinux，需要在宿主操作系统中装载 SELinux 安全性模块。
默认情况下，容器运行时递归地将 SELinux 标签赋予所有 Pod 卷上的所有文件。 为了加快该过程，Kubernetes 使用挂载可选项 -o context=<label> 可以立即改变卷的 SELinux 标签。
要使用这项加速功能，必须满足下列条件：
1、必须启用 ReadWriteOncePod 和 SELinuxMountReadWriteOncePod 特性门控。
2、Pod 必须以 accessModes: [“ReadWriteOncePod”] 模式使用 PersistentVolumeClaim。
3、Pod（或其中使用 PersistentVolumeClaim 的所有容器）必须设置 seLinuxOptions。
4、对应的 PersistentVolume 必须是：
- 使用传统树内（In-Tree） iscsi、rbd 或 fs 卷类型的卷；
- 或者是使用 {< glossary_tooltip text=”CSI” term_id=”csi” >}} 驱动程序的卷 CSI 驱动程序必须能够通过在 CSIDriver 实例中设置 spec.seLinuxMount: true 以支持 -o context 挂载。
对于所有其他卷类型，重打 SELinux 标签的方式有所不同： 容器运行时为卷中的所有节点（文件和目录）递归地修改 SELinux 标签。 卷中的文件和目录越多，重打标签需要耗费的时间就越长。
九、讨论
Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的卷（如果有的话）。 尤其是，fsGroup 和 seLinuxOptions 按下面的方式应用到挂载卷上：
1、fsGroup：支持属主管理的卷会被修改，将其属主变更为 fsGroup 所指定的 GID， 并且对该 GID 可写。
2、seLinuxOptions：支持 SELinux 标签的卷会被重新打标签，以便可被 seLinuxOptions 下所设置的标签访问。通常只需要设置 level 部分。 该部分设置的是赋予 Pod 中所有容器及卷的 多类别安全性（Multi-Category Security，MCS)标签。
注意： 在为 Pod 设置 MCS 标签之后，所有带有相同标签的 Pod 可以访问该卷。 如果需要跨 Pod 的保护，必须为每个 Pod 赋予独特的 MCS 标签。
十、清理
删除之前创建的所有 Pod：
kubectl delete pod security-context-demo kubectl delete pod security-context-demo-2 kubectl delete pod security-context-demo-3 kubectl delete pod security-context-demo-4
