Kubernetes Pod 安全性标准（Security Standards） 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
作为一项 Beta 功能特性，Kubernetes 提供一种内置的 Pod 安全性 作为 PodSecurityPolicies (opens new window)特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 名称空间 层面实施的。
Note
PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中移除。
#启用 PodSecurity 准入插件
在 v1.23 中，PodSecurity 特性门控 (opens new window)是一项 Beta 功能特性，默认被启用。
在 v1.22 中，PodSecurity 特性门控 (opens new window)是一项 Alpha 功能特性，必须在 kube-apiserver 上启用才能使用内置的准入插件。
--feature-gates="...,PodSecurity=true"
#替代方案：安装 PodSecurity 准入 Webhook
对于无法应用内置 PodSecurity 准入插件的环境，无论是因为集群版本低于 v1.22， 或者 PodSecurity 特性无法被启用，都可以使用 Beta 版本的 验证性准入 Webhook (opens new window)。 来使用 PodSecurity 准入逻辑。
在 https://git.k8s.io/pod-security-admission/webhook (opens new window)上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。
git clone [email protected]:kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
make certs
kubectl apply -k .
2
3
4
Note
所生成的证书合法期限为 2 年。在证书过期之前， 需要重新生成证书或者去掉 Webhook 以使用内置的准入查件。
#Pod 安全性级别
Pod 安全性准入插件对 Pod 的安全性上下文 有一定的要求，并且依据 Pod 安全性标准 所定义的三个级别（privileged、baseline 和 restricted）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 Pod 安全性标准页面。
#为名字空间设置 Pod 安全性准入控制标签
一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 Kubernetes 定义了一组标签， 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 你所选择的标签定义了检测到潜在违例时，控制面板要采取什么样的动作。
| 模式 | 描述 |
|---|---|
| enforce | 策略违例会导致 Pod 被拒绝 |
| audit | 策略违例会触发审计日志 (opens new window)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。 |
| warn | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。 |
名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。
对于每种模式，决定所使用策略的标签有两个：
# 针对模式的级别标签用来标示针对该模式所应用的策略级别
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一
pod-security.kubernetes.io/<MODE>: <LEVEL>
# 可选：针对每个模式版本的版本标签可以将策略锁定到
# 给定 Kubernetes 小版本号所附带的版本（例如 v1.23.5）
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest`
pod-security.kubernetes.io/<MODE>-version: <VERSION>
2
3
4
5
6
7
8
9
10
11
12
关于用法示例，可参阅 使用名字空间标签来强制实施 Pod 安全标准 (opens new window)。
#负载资源和 Pod 模板
Pod 通常是通过创建 Deployment 或 Job 这类工作负载对象 来间接创建的。工作负载对象为工作负载资源定义一个 Pod 模板 和一个对应的 负责基于该模板来创建 Pod 的 控制器。 为了尽早地捕获违例状况，audit 和 warn 模式都应用到负载资源。 不过，enforce 模式并 不 应用到工作负载资源，仅应用到所生成的 Pod 对象上。
#豁免
你可以为 Pod 安全性的实施设置 豁免（Exemptions） 规则， 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 豁免规则可以在准入控制器配置 中静态配置。
豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 忽略 （所有 enforce、audit 和 warn 行为都会被略过）。 豁免的维度包括：
- Username： 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。
- RuntimeClassName： 指定了已豁免的运行时类名称的 Pod 和负载资源会被忽略。
- Namespace： 位于被豁免的名字空间中的 Pod 和负载资源 会被忽略。
WARNING
大多数 Pod 是作为对工作负载资源的响应， 由控制器所创建的，这意味着为某最终用户提供豁免时，只会当该用户直接创建 Pod 时对其实施安全策略的豁免。用户创建工作负载资源时不会被豁免。 控制器服务账号（例如：system:serviceaccount:kube-system:replicaset-controller） 通常不应该被豁免，因为豁免这类服务账号隐含着对所有能够创建对应工作负载资源的用户豁免。
策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod 更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。
- 除了对 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作：
seccomp.security.alpha.kubernetes.io/pod（已弃用）container.seccomp.security.alpha.kubernetes.io/*（已弃用）container.apparmor.security.beta.kubernetes.io/*
- 对
.spec.activeDeadlineSeconds的合法更新 - 对
.spec.tolerations的合法更新