Pod 安全准入

Pod 安全性准入控制器概述,该控制器可强制执行 Pod 安全性标准。
功能状态: Kubernetes v1.25 [稳定]

Kubernetes Pod 安全性标准 为 Pod 定义了不同的隔离级别。这些标准允许您以清晰、一致的方式定义您想要限制的 Pod 行为。

Kubernetes 提供了一个内置的 Pod 安全性 准入控制器来强制执行 Pod 安全性标准。Pod 安全限制是在创建 Pod 时在命名空间级别应用的。

内置 Pod 安全性准入强制执行

此页面是 Kubernetes v1.36 文档的一部分。如果您运行的是不同版本的 Kubernetes,请查阅该版本的文档。

Pod 安全性级别

Pod 安全性准入根据 Pod 安全性标准定义的三个级别(`privileged`、`baseline` 和 `restricted`)对 Pod 的安全上下文及其他相关字段提出要求。请参阅 Pod 安全性标准页面以深入了解这些要求。

命名空间的 Pod 安全性准入标签

一旦启用该功能或安装了 Webhook,您就可以配置命名空间,以定义要在每个命名空间中使用的 Pod 安全性准入控制模式。Kubernetes 定义了一组标签,您可以设置这些标签来定义您想要为命名空间使用哪种预定义的 Pod 安全性标准级别。您选择的标签定义了如果检测到潜在违规行为时,控制平面所采取的行动。

Pod 安全性准入模式
模式描述
enforce策略违规将导致 Pod 被拒绝。
audit策略违规将触发在审计日志中记录的事件添加审计注解,但除此之外是允许的。
warn策略违规将触发面向用户的警告,但除此之外是允许的。

命名空间可以配置任何或所有模式,甚至可以为不同的模式设置不同的级别。

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

# The per-mode level label indicates which policy level to apply for the mode.
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# LEVEL must be one of `privileged`, `baseline`, or `restricted`.
pod-security.kubernetes.io/<MODE>: <LEVEL>

# Optional: per-mode version label that can be used to pin the policy to the
# version that shipped with a given Kubernetes minor version (for example v1.36).
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# VERSION must be a valid Kubernetes minor version, or `latest`.
pod-security.kubernetes.io/<MODE>-version: <VERSION>

查看通过命名空间标签强制执行 Pod 安全性标准以了解示例用法。

工作负载资源与 Pod 模板

Pod 通常是通过创建工作负载对象(例如 DeploymentJob)来间接创建的。工作负载对象定义了一个 Pod 模板,该工作负载资源的控制器会基于该模板创建 Pod。为了有助于尽早发现违规行为,审计和警告模式都应用于工作负载资源。但是,enforce 模式应用于工作负载资源,仅应用于由此产生的 Pod 对象。

豁免

您可以定义 Pod 安全性强制执行的 豁免 (exemptions),以允许创建由于给定命名空间关联的策略而被禁止的 Pod。豁免可以在 准入控制器配置 中进行静态配置。

豁免必须明确列出。满足豁免标准的请求将被准入控制器 忽略(所有的 enforceauditwarn 行为都将被跳过)。豁免维度包括

  • 用户名:来自具有豁免认证(或模拟)用户名的用户的请求将被忽略。
  • RuntimeClassNames:指定了豁免运行时类名的 Pod 和 工作负载资源 将被忽略。
  • 命名空间:位于豁免命名空间中的 Pod 和 工作负载资源 将被忽略。

注意

大多数 Pod 是由控制器响应 工作负载资源 而创建的,这意味着豁免最终用户只会在直接创建 Pod 时免于强制执行,但在创建工作负载资源时不会免除。控制器服务账户(例如 system:serviceaccount:kube-system:replicaset-controller)通常不应被豁免,因为这样做会隐式豁免任何能够创建相应工作负载资源的用户。

对以下 Pod 字段的更新免于策略检查,这意味着如果 Pod 更新请求仅更改这些字段,即使 Pod 违反了当前的策略级别,它也不会被拒绝:

  • 任何元数据更新,除了对 seccomp 或 AppArmor 注解的更改
    • seccomp.security.alpha.kubernetes.io/pod (已弃用)
    • container.seccomp.security.alpha.kubernetes.io/* (已弃用)
    • container.apparmor.security.beta.kubernetes.io/* (已弃用)
  • .spec.activeDeadlineSeconds 的有效更新
  • .spec.tolerations 的有效更新

指标

以下是 kube-apiserver 公开的 Prometheus 指标:

  • pod_security_errors_total:此指标表示阻止正常评估的错误数量。非致命错误可能导致强制执行时使用最新的限制配置文件。
  • pod_security_evaluations_total:此指标表示已发生的策略评估数量,不包括导出期间被忽略或豁免的请求。
  • pod_security_exemptions_total:此指标表示豁免请求的数量,不包括被忽略或超出范围的请求。

接下来

如果您正在运行较旧版本的 Kubernetes,并希望升级到不包含 PodSecurityPolicies 的 Kubernetes 版本,请阅读 从 PodSecurityPolicy 迁移到内置 PodSecurity 准入控制器


最后修改于 2024 年 3 月 7 日 下午 4:54 PST:AppArmor v1.30 文档更新 (4f11f83a45)