为 Pod 或容器配置安全性上下文
为 Pod 或容器配置安全性上下文
安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：
- 自主访问控制（Discretionary Access Control）：基于 用户 ID（UID）和组 ID（GID）. 来判定对对象（例如文件）的访问权限。
- 安全性增强的 Linux（SELinux）： 为对象赋予安全性标签。
- 以特权模式或者非特权模式运行。
-
Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。
-
AppArmor：使用程序框架来限制个别程序的权能。
- Seccomp：过滤进程的系统调用。
- AllowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置
no_new_privs标志。 当容器以特权模式运行或者具有CAP_SYS_ADMIN权能时，AllowPrivilegeEscalation 总是为 true。 - readOnlyRootFilesystem：以只读方式加载容器的根文件系统。
以上条目不是安全上下文设置的完整列表 — 请参阅 SecurityContext 了解其完整列表。
关于在 Linux 系统中的安全机制的更多信息，可参阅 Linux 内核安全性能力概述。
准备开始
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群，你可以通过 Minikube 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
要获知版本信息，请输入 kubectl version.
为 Pod 设置安全性上下文
要为 Pod 设置安全性设置，可在 Pod 规约中包含 securityContext 字段。securityContext 字段值是一个 PodSecurityContext 对象。你为 Pod 所设置的安全性配置会应用到 Pod 中所有 Container 上。 下面是一个 Pod 的配置文件，该 Pod 定义了 securityContext 和一个 emptyDir 卷：
pods/security/security-context.yaml 
apiVersion: v1kind: Podmetadata:name: security-context-demospec:securityContext:runAsUser: 1000runAsGroup: 3000fsGroup: 2000volumes:- name: sec-ctx-volemptyDir: {}containers:- name: sec-ctx-demoimage: busyboxcommand: [ "sh", "-c", "sleep 1h" ]volumeMounts:- name: sec-ctx-volmountPath: /data/demosecurityContext: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 COMMAND1 1000 0:00 sleep 1h6 1000 0:00 sh...
在你的 Shell 中，进入 /data 目录列举其内容：
cd /datals -l
输出显示 /data/demo 目录的组 ID 为 2000，即 fsGroup 的设置值：
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
在你的 Shell 中，进入到 /data/demo 目录下创建一个文件：
cd demoecho 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
为 Pod 配置卷访问权限和属主变更策略
FEATURE STATE: Kubernetes v1.20 [beta]
默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限，使之与 Pod 的 securityContext 中指定的 fsGroup 匹配。 对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。 你可以在 securityContext 中使用 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷属主和访问权限的方式。
fsGroupChangePolicy - fsGroupChangePolicy 定义在卷被暴露给 Pod 内部之前对其 内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 fsGroup 来 控制属主与访问权限的卷类型。此字段的取值可以是：
OnRootMismatch：只有根目录的属主与访问权限与卷所期望的权限不一致时， 才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问 权限所需要的时间。Always：在挂载卷时总是更改卷中内容的属主和访问权限。
例如：
securityContext:runAsUser: 1000runAsGroup: 3000fsGroup: 2000fsGroupChangePolicy: "OnRootMismatch"
这是一个 Alpha 阶段的功能特性。要使用此特性，需要在 kube-apiserver、kube-controller-manager 和 kubelet 上启用 ConfigurableFSGroupPolicy 特性门控。
为 Container 设置安全性上下文
若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置 在与 Pod 层面设置的内容发生重叠时，会重载后者。Container 层面的设置不会影响 到 Pod 的卷。
下面是一个 Pod 的配置文件，其中包含一个 Container。Pod 和 Container 都有 securityContext 字段：
pods/security/security-context-2.yaml
apiVersion: v1kind: Podmetadata:name: security-context-demo-2spec:securityContext:runAsUser: 1000containers:- name: sec-ctx-demo-2image: gcr.io/google-samples/node-hello:1.0securityContext:runAsUser: 2000allowPrivilegeEscalation: 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 COMMAND2000 1 0.0 0.0 4336 764 ? Ss 20:36 0:00 /bin/sh -c node server.js2000 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 字段时候会发生什么。 下面是一个配置文件，其中没有添加或移除容器的权能：
pods/security/security-context-3.yaml
apiVersion: v1kind: Podmetadata:name: security-context-demo-3spec:containers:- name: sec-ctx-3image: 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 COMMANDroot 1 0.0 0.0 4336 796 ? Ss 18:17 0:00 /bin/sh -c node server.jsroot 5 0.1 0.5 772124 22700 ? Sl 18:17 0:00 node server.js
在你的 Shell 中，查看进程 1 的状态：
cd /proc/1cat status
输出显示进程的权能位图：
...CapPrm: 00000000a80425fbCapEff: 00000000a80425fb...
记下进程权能位图，之后退出你的 Shell：
exit
接下来运行一个与前例中容器相同的容器，只是这个容器有一些额外的权能设置。
下面是一个 Pod 的配置，其中运行一个容器。配置为容器添加 CAP_NET_ADMIN 和 CAP_SYS_TIME 权能：
pods/security/security-context-4.yaml
apiVersion: v1kind: Podmetadata:name: security-context-demo-4spec:containers:- name: sec-ctx-4image: gcr.io/google-samples/node-hello:1.0securityContext: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/1cat status
输出显示的是进程的权能位图：
...CapPrm: 00000000aa0435fbCapEff: 00000000aa0435fb...
比较两个容器的权能位图：
00000000a80425fb00000000aa0435fb
在第一个容器的权能位图中，位 12 和 25 是没有设置的。在第二个容器中，位 12 和 25 是设置了的。位 12 是 CAP_NET_ADMIN 而位 25 则是 CAP_SYS_TIME。 参见 capability.h 了解权能常数的定义。
说明： 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: LocalhostlocalhostProfile: my-profiles/profile-allow.json
为 Container 赋予 SELinux 标签
若要给 Container 设置 SELinux 标签，可以在 Pod 或 Container 清单的 securityContext 节包含 seLinuxOptions 字段。 seLinuxOptions 字段的取值是一个 SELinuxOptions 对象。下面是一个应用 SELinux 标签的例子：
...securityContext:seLinuxOptions:level: "s0:c123,c456"
说明： 要指定 SELinux，需要在宿主操作系统中装载 SELinux 安全性模块。
讨论
Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的卷（如果有的话）。 尤其是，fsGroup 和 seLinuxOptions 按下面的方式应用到挂载卷上：
-
fsGroup：支持属主管理的卷会被修改，将其属主变更为fsGroup所指定的 GID， 并且对该 GID 可写。进一步的细节可参阅 属主变更设计文档。 -
seLinuxOptions：支持 SELinux 标签的卷会被重新打标签，以便可被seLinuxOptions下所设置的标签访问。通常你只需要设置level部分。 该部分设置的是赋予 Pod 中所有容器及卷的 多类别安全性（Multi-Category Security，MCS)标签。警告： 在为 Pod 设置 MCS 标签之后，所有带有相同标签的 Pod 可以访问该卷。 如果你需要跨 Pod 的保护，你必须为每个 Pod 赋予独特的 MCS 标签。
清理
删除之前创建的所有 Pod：
kubectl delete pod security-context-demokubectl delete pod security-context-demo-2kubectl delete pod security-context-demo-3kubectl delete pod security-context-demo-4
接下来
- PodSecurityContext API 定义
- SecurityContext API 定义
- 使用最新的安全性增强来调优 Docker
- 安全性上下文的设计文档
- 属主管理的设计文档
- Pod 安全策略
- AllowPrivilegeEscalation 的设计文档