Kubernetes 中的 Pod 安全策略（PSP）替代方案：PSA 实践

好嘞！没问题！各位观众老爷，今天咱们来聊聊 Kubernetes 里的“安保大哥”—— Pod 安全策略（Pod Security Policy，简称 PSP）的退休以及它的继任者—— Pod 安全准入（Pod Security Admission，简称 PSA）。话说这 PSP 啊，曾经也是风光无限，肩负着守护 Pod 安全的重任。但江湖上混久了，难免会遇到一些问题，比如配置复杂、难以管理，让不少运维小哥挠破了头。终于，在 Kubernetes 1.25 版本里，PSP 正式宣布退休，把接力棒交给了 PSA。 PSA 这位新秀，不仅继承了 PSP 的安全理念，还在易用性和管理性上做了大幅提升，简直是“青出于蓝而胜于蓝”啊！那么，今天咱们就来好好剖析一下 PSP 的“前世今生”，以及 PSA 的“十八般武艺”，让大家彻底搞懂如何在 Kubernetes 里玩转 Pod 安全！

一、PSP 的“前世今生”：一位功成身退的“老大哥”

在 Kubernetes 的早期，Pod 安全管理是一片“蛮荒之地”，大家各凭本事，安全风险也是层出不穷。为了规范 Pod 的安全行为，Kubernetes 引入了 PSP。简单来说，PSP 就像一份“安全协议”，定义了 Pod 必须遵守的安全规则，比如：

是否允许使用特权模式（Privileged）？ 允许 Pod 拥有 root 权限，但风险也最大。
是否允许挂载 HostPath 卷？ 允许 Pod 访问宿主机的文件系统，但也可能被恶意利用。
是否限制 Pod 使用的 Linux Capabilities？ Capabilities 可以细粒度地控制 Pod 的权限，避免过度授权。
是否强制 Pod 使用特定的用户 ID 和组 ID？ 避免 Pod 以 root 用户运行，降低安全风险。

通过 PSP，我们可以对 Pod 的安全行为进行细粒度的控制，从而提升整个集群的安全性。但是，PSP 也存在一些问题：

配置复杂： PSP 的配置非常繁琐，需要深入理解 Kubernetes 的各种安全概念。
难以管理： PSP 的生效需要依赖 RBAC 授权，管理起来比较复杂，容易出错。
排错困难： 当 Pod 违反 PSP 策略时，Kubernetes 的报错信息不够友好，排错比较困难。

总而言之，PSP 虽然功能强大，但使用门槛较高，给运维人员带来了不小的负担。因此，Kubernetes 社区决定引入 PSA，以替代 PSP。

二、PSA 的“十八般武艺”：一位“平易近人”的“安全卫士”

PSA 是一种内置的 Kubernetes 准入控制器，它通过给 Namespace 打标签的方式，来定义 Pod 的安全级别。 PSA 预定义了三个安全级别：

Privileged（特权）： 允许 Pod 执行任何操作，相当于关闭了所有安全限制。
Baseline（基线）： 遵循最小特权原则，禁止 Pod 执行一些高危操作，例如使用特权模式、挂载 HostPath 卷等。
Restricted（受限）： 实施最严格的安全限制，进一步限制 Pod 的权限，例如禁止使用某些 Linux Capabilities、强制使用非 root 用户等。

我们可以通过给 Namespace 打上不同的标签，来指定该 Namespace 下 Pod 的安全级别。例如，如果我们要将某个 Namespace 的安全级别设置为 Baseline，可以执行以下命令：

kubectl label ns <namespace_name> 
  pod-security.kubernetes.io/enforce=baseline 
  pod-security.kubernetes.io/warn=baseline 
  pod-security.kubernetes.io/audit=baseline

这里解释一下这三个标签的作用：

enforce：强制执行安全级别，如果 Pod 违反了该级别的安全策略，则会被拒绝创建。
warn：发出警告，如果 Pod 违反了该级别的安全策略，则会发出警告，但仍然允许创建。
audit：记录审计日志，如果 Pod 违反了该级别的安全策略，则会记录审计日志，方便后续分析。

通过这种简单的标签方式，我们可以轻松地管理 Pod 的安全级别，而无需编写复杂的 PSP 策略。此外，PSA 还具有以下优点：

易于使用： PSA 的配置非常简单，只需要给 Namespace 打标签即可。
易于管理： PSA 是内置的准入控制器，无需额外的配置和维护。
排错方便： 当 Pod 违反 PSA 策略时，Kubernetes 的报错信息更加友好，方便排错。
兼容性好： PSA 可以与其他的安全工具集成，例如 OPA（Open Policy Agent）。

总而言之，PSA 是一种更加易用、易管理、易排错的 Pod 安全解决方案，是 PSP 的理想替代品。

三、PSP 与 PSA 的对比：新老交替，各有千秋

为了更直观地了解 PSP 和 PSA 的区别，我们用一张表格来对比一下：

特性	PSP	PSA
配置方式	YAML 文件	Namespace 标签
管理方式	RBAC 授权	内置准入控制器
安全级别	自定义	Privileged、Baseline、Restricted
易用性	复杂	简单
管理性	复杂	简单
排错性	困难	方便
兼容性	一般	良好
是否需要额外安装	需要	内置
适用场景	需要自定义安全策略的场景	追求简单易用的场景

从上表可以看出，PSP 更加灵活，可以自定义安全策略，适用于对安全性要求非常高的场景。而 PSA 更加易用，配置简单，适用于追求简单易用的场景。就像武侠小说里的“独孤九剑”和“太极剑法”，前者精妙绝伦，后者四两拨千斤，各有千秋。

四、PSA 实战演练：手把手教你玩转 Pod 安全

光说不练假把式，接下来咱们就来做一个 PSA 的实战演练，让大家亲身体验一下 PSA 的魅力。

1. 创建一个 Namespace

首先，我们创建一个名为 test-ns 的 Namespace：

kubectl create ns test-ns

2. 设置 Namespace 的安全级别

接下来，我们将 test-ns 的安全级别设置为 Baseline：

kubectl label ns test-ns 
  pod-security.kubernetes.io/enforce=baseline 
  pod-security.kubernetes.io/warn=baseline 
  pod-security.kubernetes.io/audit=baseline

3. 创建一个违反 Baseline 策略的 Pod

现在，我们创建一个使用特权模式的 Pod，这违反了 Baseline 策略：

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: test-ns
spec:
  containers:
  - name: privileged-container
    image: busybox
    securityContext:
      privileged: true
    command: ["sleep", "3600"]

执行以下命令创建 Pod：

kubectl apply -f privileged-pod.yaml

4. 观察 Kubernetes 的行为

由于我们设置了 enforce=baseline，因此 Kubernetes 会拒绝创建该 Pod，并返回如下错误信息：

Error from server: admission webhook "pod-security.kubernetes.io" denied the request:
  Pod "privileged-pod" is invalid: spec.containers[0].securityContext.privileged:
    Forbidden: privileged mode is disallowed

同时，我们还会收到一条警告信息，提示该 Pod 违反了 Baseline 策略。如果我们将 enforce 设置为 warn，则 Kubernetes 会允许创建该 Pod，但会发出一条警告信息。如果我们将 enforce 设置为 audit，则 Kubernetes 会允许创建该 Pod，但会记录一条审计日志。

5. 创建一个符合 Baseline 策略的 Pod

最后，我们创建一个符合 Baseline 策略的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: non-privileged-pod
  namespace: test-ns
spec:
  containers:
  - name: non-privileged-container
    image: busybox
    command: ["sleep", "3600"]

执行以下命令创建 Pod：

kubectl apply -f non-privileged-pod.yaml

由于该 Pod 符合 Baseline 策略，因此 Kubernetes 会允许创建该 Pod。通过这个简单的例子，相信大家已经对 PSA 的使用方法有了一个初步的了解。

五、PSA 的高级用法：玩转自定义策略

虽然 PSA 预定义了三个安全级别，但在某些情况下，我们可能需要自定义安全策略。幸运的是，PSA 提供了灵活的扩展机制，允许我们使用其他的安全工具，例如 OPA，来实现自定义策略。 OPA 是一种通用的策略引擎，可以用于各种场景，包括 Kubernetes 的准入控制。我们可以使用 OPA 来定义自己的安全策略，并将 OPA 集成到 PSA 中，从而实现更加灵活的 Pod 安全管理。具体的集成方法比较复杂，这里就不展开讲解了，感兴趣的同学可以自行查阅相关资料。

六、PSP 的“遗产”：如何平滑过渡到 PSA？

虽然 PSP 已经退休，但我们仍然需要考虑如何平滑地从 PSP 过渡到 PSA。 Kubernetes 社区提供了一些工具和方法，可以帮助我们完成这个过渡：

Pod Security Standards（PSS）： PSS 是一组预定义的安全标准，与 PSA 的三个安全级别相对应。我们可以使用 PSS 来评估现有的 PSP 策略，并将其转换为 PSA 的配置。
kubectl convert 命令： kubectl convert 命令可以将 PSP 策略转换为 PSA 的配置。
逐步迁移： 我们可以逐步地将 PSP 策略迁移到 PSA，先从一些不太重要的 Namespace 开始，逐步扩大范围。

总而言之，从 PSP 过渡到 PSA 需要一定的规划和准备，但只要掌握了正确的方法，就可以顺利完成这个过渡。

七、总结：拥抱 PSA，守护你的 Kubernetes 集群

好了，各位观众老爷，今天的“Kubernetes 安保大讲堂”就到这里了。相信通过今天的讲解，大家已经对 PSP 和 PSA 有了一个全面的了解。 PSP 是一位功成身退的“老大哥”，而 PSA 是一位“青出于蓝而胜于蓝”的“安全卫士”。在 Kubernetes 1.25 版本之后，我们应该拥抱 PSA，利用它来守护我们的 Kubernetes 集群，让我们的应用安全无忧！记住，安全无小事，让我们一起努力，打造一个更加安全的 Kubernetes 生态！感谢大家的收看，我们下期再见！ 😉

发表回复 取消回复

发表回复取消回复