为工作负载动态注入 PSA 安全上下文
在命名空间上启用 Pod Security Admission(PSA)后,在其中创建的任何 Workload(例如 Deployment 或 StatefulSet)都必须符合指定的安全配置文件。如果 Workload 的 securityContext 不符合要求,则由该 Workload 生成的 Pod 将在 Pod 准入期间被 Kubernetes API server 拒绝,即使 Workload 资源本身已被接受。
为了简化用户体验并确保持续合规,您可以将 Kyverno 与 Alauda Container Platform Policy Management 插件结合使用,根据命名空间的 PSA 策略动态注入所需的 securityContext 字段。
前提条件
继续操作前,请确保:
- 集群中已安装并启用 Alauda Container Platform Policy Management 插件。有关安装详情,请参阅安装 Compliance 插件。
- 目标命名空间已应用 PSA 标签,例如
pod-security.kubernetes.io/enforce: restricted或baseline。
工作原理
- 命名空间标记:为命名空间分配特定的 PSA 级别(例如
restricted)。 - Kyverno 拦截:用户提交 Workload 创建请求时,Kyverno 会在准入阶段拦截该请求。
- Compliance 插件变更:Kyverno 与 Compliance 插件协同工作,读取目标命名空间的 PSA 配置。
- 动态修补:Kyverno 根据 PSA 级别,使用适当的
securityContext动态修补 Workload 的 Pod 模板(例如添加runAsNonRoot: true、删除特定 capabilities,或设置seccompProfile)。
PSA 强制执行配置
安装 Compliance 插件后,您可以应用以下 ClusterPolicy 配置。这些策略使用上下文变量查询命名空间的 pod-security.kubernetes.io/enforce 标签,并针对相应的 PSA 配置文件,在所有容器类型(包括 initContainers 和 ephemeralContainers)中应用所需的精确 securityContext 变更。
1. Restricted 策略变更
当命名空间强制执行 restricted 配置文件时,Workload 必须删除所有权限、以非 root 用户身份运行,并使用默认 seccomp 配置文件。
2. Baseline 策略变更
当命名空间强制执行 baseline 配置文件时,Workload 禁止使用主机命名空间和特权容器。
注意:对于
privilegedPSA 配置文件,无需进行变更,因为它允许不受限制的访问。
验证
要验证动态配置是否正常工作:
- 使用
restrictedPSA 标签创建命名空间: - 部署一个未指定
securityContext的简单原生应用: - 检查所创建 Pod 的 YAML 定义:
您应看到自动注入的
securityContext字段,以满足restricted配置文件的要求。