震惊！！K8s 全面升级 Pod 安全特性：PodSecurity (v1.22)

PodSecurity 是 Kubernetes 内置的 admission controller，它在安全的各个方面控制 Pod 的行为，只有满足一定的条件的 Pod 才会被系统接受。它设置三个等级和三种模式，用户可以根据自己的需求选择更加合适的方案来设置限制策略。相对比 Pod Security Policies，它提供了更大的灵活性和简洁性。Pod Security Policies 作为已经废弃的功能（v1.21 版本中被弃用，将在 v1.25 中删除），PodSecurity 将替代它，我们对它的学习更为重要。

1. 准入控制器

新的 PodSecurity 基于准入控制器，如果不了解的读者，这里简单介绍一下概念和原理。如果您对此比较熟悉，可以跳过本章节。

准入控制器是 Kubernetes API 服务器用于拦截请求的一种手段。它可以做到对请求的资源对象进行校验，修改。

在 API server 中，准入控制器是在 authn 和 authz 之后执行，而他们之间也有本质的不同：

• authn/authz 是运行在 filter 中，只能获取 http 请求 header 和证书，并不能获取请求的 body 。所以 authn/authz 只能对客户端进行认证和鉴权，不可以对请求的对象进行任何操作，因为这里根本还获取不到对象。

• 准入运行在 API Server 的增加更改日志处理程序中，可以自然操作 API 资源。它是在经过授权之后，资源持久之前化的一个处理 API 服务器的请求步骤。准入过程能够获取到和认证一致性过程的信息（用户、URL 等），以及 API 请求的完整报告。

准入控制器分为两个阶段：

• Mutation：修改阶段，在对象持久化之前，修改对象的内容或者拒绝请求。因为对象的字段可能被不同的准入控制器修改多次，所以准入控制器链的顺序就尤其重要。

• Validation：验证阶段，在对象持久化之前，校验对象的内容或者拒绝请求。验证阶段在所有的 mutators 执行完以后运行，以确保资源在做完验证之后不会被再次改变。

2. PodSecurity

PodSecurity 限制条件是作用在 namespace 的级别，在当前 namespace 创建 pod，经过 API Server 的认证和鉴权后，进入 PodSecurity 的准入控制器进行安全检查，只有通过的 Pod 才会创建成功。

3. 启用 PodSecurity

PodSecurity 目前还是 alpha 的版本，如果要使用则指定 feature-gates 启动功能，只以测试为目的。

• API server: 修改 /etc/kubernetes/manifests/kube-apiserver.yaml 文件，在 command 参数后面添加--feature-gates=PodSecurity=true，kubernetes 会重新启动 API server。

• kubelet：修改 kubelet 的配置文件 /var/lib/kubelet/config.yaml 添加配置项 featureGates.PodSecurity=true，重新启动 kubelet。

4. PodSecurity 安全级别

PodSecurity 定义的级别实现 PodSecurity Standards 的标准：

• Privileged：不受限制的策略，去开放且完全无限制的策略，默认禁止所有的限制。

• Baseline：限制性最弱的策略，将能在连接机，特权容器，权限，HostPath 卷，端口端口，AppArmor，SELinux，/proc 挂载类型，Syslsls 进行限制。

• Restricted：限制性非常强的策略，将在卷类型，特权运行，以非 root 账号非 root 组，Seccomp 进行限制。

详情查看 Reference。

5. PodSecurity 安全模式

PodSecurity 有三种模式，在 PodSecurity 的 namespace 上可以配置不同的模式。PodSecurity 定义了一组 label 可以设置在 namespace 上，在不同的模式上可以设置不同的安全级别，潜在的违规在不同的模式下将产生不同的行为。

• enforce：违规行为将会导致 Pod 被拒绝。

• audit：违规行为将触发向审计日志中记录的事件并添加审计日志。

• warn：违规行为将触发向用户发出警告。

6. 举个「栗子」

下面进行一些简单 demo，我们来看看，如何配置 PodSecurity，来达到这个效果。

我们绝大多数都是使用 Deployment 或者 Job 的 workload object 创建 Pods。workload object 定义一个 Pod template 和一个 controller 来创建 Pods。为了更早的捕获到违规行为，audit 和 warning 模式都运用在 workload 资源上。然而，enforce 模型不能运用在 workload 资源上，仅仅只能作用在 pod 的对象上。

下面是一些作用在 namespace 上的 PodSecurity 的示例：

• Privileged namespace:

apiVersion: v1
kind: Namespace
metadata:
name: my-privileged-namespace
labels:
  pod-security.kubernetes.io/enforce: privileged
  pod-security.kubernetes.io/enforce-version: latest

• Baseline namespace

apiVersion: v1
kind: Namespace
metadata:
name: my-baseline-namespace
labels:
  pod-security.kubernetes.io/enforce: baseline
  pod-security.kubernetes.io/enforce-version: latest
  pod-security.kubernetes.io/warn: baseline
  pod-security.kubernetes.io/warn-version: latest

• Restricted namespace

apiVersion: v1
kind: Namespace
metadata:
name: my-restricted-namespace
labels:
  pod-security.kubernetes.io/enforce: restricted
  pod-security.kubernetes.io/enforce-version: latest
  pod-security.kubernetes.io/warn: restricted
  pod-security.kubernetes.io/warn-version: latest

进行简单的测试：

在 restricted 级别的 enforce 和 warn 的模型下，创建 namespace。在两种模式下，如果 pod 不符合限制条件会被拒绝，然后会给用户提示信息。

创建 nginx 的 Pod:

kubectl run nginx --image=nginx:latest -n my-restricted-namespace 会出现如下的警告信息：

Error from server (Failure): allowPrivilegeEscalation != false (container "nginx" must set securityContext.

allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]),

runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true),

seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

在 my-restricted-namespace 下， pod 也没有被创建。

Exemptions可以使创建 pod 不受 Admission Controller 的限制，所有的模式包括 enforce，audit 和 warn 的行为都将跳过。Exemption 可以从这几个方面进行设置：

• Usernames: 指定的用户的请求将被限制忽略。

• RuntimeClassNames：指定运行时的 pods 和 workload 资源将被限制忽略。

• Namespace: 指定的 namespace 的 pods 和 workload 资源将被限制忽略。 Exemptions 可以在 Admission Controller 中使用静态配置的方式进行配置，也可以配置默认限制，他们都将是集群范围的。
  

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1alpha1
kind: PodSecurityConfiguration
# Defaults applied when a mode label is not set.
#
# Level label values must be one of:
# - "privileged" (default)
# - "baseline"
# - "restricted"
#
# Version label values must be one of:
# - "latest" (default)
# - specific version like "v1.22"
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  # Array of authenticated usernames to exempt.
  usernames: []
  # Array of runtime class names to exempt.
  runtimeClassNames: []
  # Array of namespaces to exempt.
  namespaces: [my-restricted-namespace]

在 API server 服务添加 adminssion controller 配置文件：

修改 /etc/kubernetes/manifests/kube-apiserver.yaml 文件，在 command 参数后面添加--admission-control-config-file=Path/admissionConfiguration.yaml。kubernetes 会自动重启 API server 服务。

7. 从 Pod Security Policies 迁移到 PodSecurity

• 先删除集群环境的 PSP。

• 为每一个命名空间找一个合适等级的策略：

  根据 Pod Security Standards 的要求，评估因禁用 PSP 控制器而产生的特权差异，如果 Pod Security Policies 介于两个级别之间，如果选择较严格的 PodSecurity 限制，可能需要调整 workloads 来满足要求，如果选择较宽松的 PodSecurity 的限制，作用在工作空间的 workloads 将会获得比预期更大的权限。
  

• 使用 warn 和 audit 模式的配置：

  先使用 warn 和 audit 模式，根据警告或者日志信息可以了解 Pod 将如何不破坏现有的 workloads 的情况下来响应新的策略，然后调整 PodSecurity 的配置直到选择合适的限制条件。

• 再运用 enforce 的模式

  在确认不会影响 workloads 的情况下，再启动 enforce 模式。

• 使用 --enable-admission-plugins 的 flag 停止 PodSecurity

PodSecurity 细节将持续更新···

8. Reference

• 🔗https://kubernetes.io/docs/concepts/security/pod-security-standards/

• 🔗https://kubernetes.io/docs/concepts/security/pod-security-admission/

• 🔗https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller

• 🔗https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/

• 🔗https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/

作者简介

陈文

Kubernetes 社区 member

从事 sig-auth 方面的工作

DaoCloud 公司简介

上海道客网络科技有限公司，成立于 2014 年底，公司拥有自主知识产权的核心技术，以云计算、人工智能为底座构建数字化操作系统为实体经济赋能，推动传统企业完成数字化转型。成立迄今，公司已在金融科技、先进制造、智能汽车、零售网点、城市大脑等多个领域深耕，标杆客户包括交通银行、浦发银行、上汽集团、东风汽车、海尔集团、金拱门（麦当劳）等。被誉为科技领域准独角兽企业。公司在北京、武汉、深圳、成都设立多家分公司及合资公司，总员工人数超过 300 人，是上海市高新技术企业、上海市“专精特新”企业和上海市“科技小巨人”企业，并入选了科创板培育企业名单。

网址：www.daocloud.io

邮件：[e-mail]

电话：400 002 6898