您正在查看 Kubernetes 版本的文档： v1.24

Kubernetes v1.24 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Pod 安全性准入

对 Pod 安全性准入控制器的概述，Pod 安全性准入控制器可以实施 Pod 安全性标准。
特性状态： Kubernetes v1.23 [beta]

Kubernetes Pod 安全性标准（Security Standards） 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。

作为一项 Beta 功能特性，Kubernetes 提供一种内置的 Pod 安全性 准入控制器， 作为 PodSecurityPolicies 特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 名字空间层面实施的。

准备开始

要使用此机制，你的集群必须强制执行 Pod 安全准入。

内置 Pod 安全准入强制执行

在 Kubernetes v1.23 中，PodSecurity 特性门控是一项 Beta 特性， 默认被启用。 本页面是 Kubernetes v1.24 文档的一部分。 如果你运行的是其它版本的 Kubernetes，请查阅该版本的文档。

替代方案：安装 PodSecurity 准入 Webhook

PodSecurity 准入逻辑也可用作验证性准入 Webhook。 该实现也是 Beta 版本。 对于无法启用内置 PodSecurity 准入插件的环境，你可以改为通过验证准入 Webhook 启用该逻辑。

在 https://git.k8s.io/pod-security-admission/webhook 上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。 执行下面的命令来安装：

git clone git@github.com:kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
make certs
kubectl apply -k .

Pod 安全性级别

Pod 安全性准入插件对 Pod 的安全性上下文 有一定的要求，并且依据 Pod 安全性标准 所定义的三个级别（privileged、baseline 和 restricted）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 Pod 安全性标准页面。

为名字空间设置 Pod 安全性准入控制标签

一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 Kubernetes 定义了一组标签， 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 你所选择的标签定义了检测到潜在违例时，控制面 要采取什么样的动作。

Pod 安全准入模式
模式描述
enforce策略违例会导致 Pod 被拒绝
audit策略违例会触发审计日志中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
warn策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。

名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。

对于每种模式，决定所使用策略的标签有两个：

# 模式的级别标签用来标示对应模式所应用的策略级别
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一
pod-security.kubernetes.io/<MODE>: <LEVEL>

# 可选：针对每个模式版本的版本标签可以将策略锁定到
# 给定 Kubernetes 小版本号所附带的版本（例如 v1.24）
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest`
pod-security.kubernetes.io/<MODE>-version: <VERSION>

关于用法示例，可参阅使用名字空间标签来强制实施 Pod 安全标准。

负载资源和 Pod 模板

Pod 通常是通过创建 Deployment 或 Job 这类工作负载对象 来间接创建的。工作负载对象为工作负载资源定义一个 Pod 模板 和一个对应的负责基于该模板来创建 Pod 的控制器。 为了尽早地捕获违例状况，audit 和 warn 模式都应用到负载资源。 不过，enforce 模式并 不 应用到工作负载资源，仅应用到所生成的 Pod 对象上。

豁免

你可以为 Pod 安全性的实施设置 豁免（Exemptions） 规则， 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 豁免规则可以在准入控制器配置 中静态配置。

豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 忽略 （所有 enforce、audit 和 warn 行为都会被略过）。 豁免的维度包括：

  • Username： 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。
  • RuntimeClassName： 指定了已豁免的运行时类名称的 Pod 和负载资源会被忽略。
  • Namespace： 位于被豁免的名字空间中的 Pod 和负载资源 会被忽略。

策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod 更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。

  • 除了对 seccomp 或 AppArmor 注解之外的所有元数据（Metadata）更新操作：
    • seccomp.security.alpha.kubernetes.io/pod （已弃用）
    • container.seccomp.security.alpha.kubernetes.io/* （已弃用）
    • container.apparmor.security.beta.kubernetes.io/*
  • 对 .spec.activeDeadlineSeconds 的合法更新
  • 对 .spec.tolerations 的合法更新

接下来

最后修改 November 14, 2023 at 2:21 PM PST: Merge pull request #43918 from xmudrii/follow-up-43522-1.24 (98e2db7)