Pod 安全性准入
FEATURE STATE: Kubernetes v1.23 [beta]
Kubernetes Pod 安全性标准(Security Standards) 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
作为一项 Beta 功能特性,Kubernetes 提供一种内置的 Pod 安全性 , 作为 PodSecurityPolicies 特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 层面实施的。
Note:
PodSecurityPolicy API 已经被废弃,会在 Kubernetes v1.25 发行版中 移除。
在 v1.23 中,PodSecurity
是一项 Beta 功能特性,默认被启用。
在 v1.22 中,PodSecurity
特性门控 是一项 Alpha 功能特性,必须在 kube-apiserver
上启用才能使用内置的准入插件。
替代方案:安装 PodSecurity
准入 Webhook
在 https://git.k8s.io/pod-security-admission/webhook 上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。
Note:
所生成的证书合法期限为 2 年。在证书过期之前, 需要重新生成证书或者去掉 Webhook 以使用内置的准入查件。
Pod 安全性准入插件对 Pod 的 有一定的要求,并且依据 Pod 安全性标准 所定义的三个级别(privileged
、baseline
和 restricted
)对其他字段也有要求。 关于这些需求的更进一步讨论,请参阅 页面。
为名字空间设置 Pod 安全性准入控制标签
一旦特性被启用或者安装了 Webhook,你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 Kubernetes 定义了一组, 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 你所选择的标签定义了检测到潜在违例时,控制面 要采取什么样的动作。
名字空间可以配置任何一种或者所有模式,或者甚至为不同的模式设置不同的级别。
对于每种模式,决定所使用策略的标签有两个:
Pod 通常是通过创建 或 Job 这类 来间接创建的。工作负载对象为工作负载资源定义一个 Pod 模板 和一个对应的 负责基于该模板来创建 Pod 的控制器。 为了尽早地捕获违例状况,audit
和 warn
模式都应用到负载资源。 不过, 模式并 不 应用到工作负载资源,仅应用到所生成的 Pod 对象上。
豁免
你可以为 Pod 安全性的实施设置 豁免(Exemptions) 规则, 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 豁免规则可以在准入控制器配置 中静态配置。
豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 忽略 (所有 enforce
、audit
和 warn
行为都会被略过)。 豁免的维度包括:
- Username: 来自用户名已被豁免的、已认证的(或伪装的)的用户的请求会被忽略。
- RuntimeClassName: 指定了已豁免的运行时类名称的 Pod 和会被忽略。
- Namespace: 位于被豁免的名字空间中的 Pod 和负载资源 会被忽略。
Caution:
大多数 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/*
(已弃用)
- 对 的合法更新
- 对
.spec.tolerations
的合法更新
最后修改 April 01, 2022 at 5:48 PM PST: [zh] Update pod-security-admission.md (07a430e1a)