Pod 安全策略（PSP）到 Pod 安全标准（PSS）过渡指南：优缺点对比与实践迁移

在 Kubernetes 集群中，保障 Pod 的安全性至关重要。曾经，Pod 安全策略（Pod Security Policy, PSP）是实现这一目标的主要手段。然而，随着 Kubernetes 的发展，PSP 已经逐渐被弃用，取而代之的是更为灵活和强大的 Pod 安全标准（Pod Security Standards, PSS）。本文将深入探讨 PSP 和 PSS 的优缺点，并提供从 PSP 迁移到 PSS 的实用指南，帮助你更好地保护 Kubernetes 集群的安全。希望本文能对运维工程师和安全工程师有所帮助。

PSP：曾经的安全卫士

PSP 是一种集群级别的资源，用于控制 Pod 的安全敏感行为。通过定义 PSP，管理员可以限制 Pod 可以使用的资源、权限以及安全上下文。PSP 能够有效防止恶意 Pod 逃逸容器、访问主机资源或执行特权操作。

PSP 的优点

• 细粒度控制：PSP 允许管理员对 Pod 的安全属性进行精细控制，例如限制 hostNetwork、hostPID、hostIPC 的使用，以及强制容器以非 root 用户身份运行。
• 集群级别策略：PSP 是集群级别的资源，可以方便地应用于整个集群或特定的命名空间，实现统一的安全策略。
• 准入控制：PSP 通过准入控制器强制执行安全策略，阻止不符合策略的 Pod 创建或更新。

PSP 的缺点

• 配置复杂：PSP 的配置相对复杂，需要深入理解 Kubernetes 的安全概念和资源属性。编写和维护 PSP 可能会带来较高的管理成本。
• 策略冲突：当多个 PSP 同时应用于一个 Pod 时，可能会出现策略冲突，导致 Pod 无法正常创建或运行。解决策略冲突需要仔细分析和调整 PSP 的配置。
• 缺乏灵活性：PSP 的静态配置方式缺乏灵活性，难以适应快速变化的业务需求。例如，当需要为特定 Pod 临时提升权限时，需要修改 PSP 的配置，这可能会影响其他 Pod 的安全。
• 逐步弃用：Kubernetes 官方已经宣布弃用 PSP，并计划在未来的版本中移除。这意味着投入大量精力维护 PSP 并不是一个长远之计。

PSS：新的安全标准

为了解决 PSP 的缺点，Kubernetes 社区引入了 Pod 安全标准（Pod Security Standards, PSS）。PSS 是一组预定义的 Pod 安全配置，旨在提供一种更简单、更灵活的方式来定义和实施 Pod 安全策略。

PSS 的三个级别

PSS 定义了三个不同的安全级别，分别是：

• Privileged：特权级，该级别不对 Pod 的安全属性进行任何限制，允许 Pod 执行所有操作。适用于系统级别的 Pod，例如 Kubernetes 的核心组件。
• Baseline：基线级，该级别提供了一组最小的安全限制，旨在阻止已知的特权提升漏洞。适用于大多数应用场景。
• Restricted：受限级，该级别提供了最严格的安全限制，旨在最大程度地降低 Pod 的安全风险。适用于对安全性要求极高的应用场景。

PSS 的优点

• 简单易用：PSS 是一组预定义的标准，无需编写复杂的安全策略。管理员只需要选择合适的安全级别，即可轻松应用到 Pod 上。
• 灵活性：PSS 允许管理员在命名空间级别或 Pod 级别设置安全级别，从而实现更灵活的安全策略。例如，可以为整个命名空间设置 Baseline 级别，然后为特定的 Pod 设置 Restricted 级别。
• 标准化：PSS 是一组标准化的安全配置，可以方便地在不同的 Kubernetes 集群之间移植。这有助于提高应用的可移植性和安全性。
• 与 Kubernetes 集成：PSS 与 Kubernetes 的准入控制器集成，可以自动强制执行安全策略。当 Pod 不符合安全级别要求时，准入控制器会阻止 Pod 的创建或更新。
• 可持续性：PSS 是 Kubernetes 官方推荐的安全策略方案，将会得到持续的维护和更新。选择 PSS 可以避免未来因 PSP 被移除而带来的兼容性问题。

PSS 的缺点

• 缺乏细粒度控制：PSS 提供的安全级别是预定义的，无法像 PSP 那样进行细粒度的安全控制。例如，无法单独限制 hostNetwork 的使用，或者强制容器以特定的非 root 用户身份运行。
• 策略覆盖：PSS 的安全级别是相互覆盖的，例如 Restricted 级别包含了 Baseline 级别的所有限制。这可能会导致某些 Pod 受到不必要的限制。

PSP 与 PSS 的对比

从 PSP 迁移到 PSS

由于 PSP 已经被弃用，建议尽快将安全策略迁移到 PSS。以下是从 PSP 迁移到 PSS 的步骤：

1. 评估现有的 PSP

首先，需要仔细评估现有的 PSP，了解其限制了哪些安全属性。可以使用 kubectl get psp 命令查看集群中的 PSP 列表，并使用 kubectl describe psp <psp-name> 命令查看 PSP 的详细配置。

分析 PSP 的配置，确定哪些限制是必须保留的，哪些可以放宽。例如，如果 PSP 强制容器以非 root 用户身份运行，那么在迁移到 PSS 时，也应该尽可能保持这一限制。

2. 选择合适的 PSS 级别

根据 PSP 的评估结果，选择合适的 PSS 级别。一般来说，可以按照以下原则进行选择：

• 如果 PSP 的限制较为宽松，可以选择 Baseline 级别。
• 如果 PSP 的限制较为严格，可以选择 Restricted 级别。
• 如果 PSP 的限制非常特殊，PSS 无法完全满足需求，可以考虑自定义准入控制器。

3. 应用 PSS 级别

PSS 级别可以通过以下两种方式应用：

• 命名空间级别：在命名空间上添加以下标签，可以为整个命名空间设置 PSS 级别。

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

*   `enforce`：强制执行 PSS 级别，阻止不符合要求的 Pod 创建或更新。
*   `warn`：发出警告，提示 Pod 不符合 PSS 级别，但允许 Pod 创建或更新。
*   `audit`：记录审计日志，记录 Pod 是否符合 PSS 级别。

• Pod 级别：在 Pod 的 securityContext 中添加以下配置，可以为单个 Pod 设置 PSS 级别。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    pod-security.kubernetes.io/enforce: baseline
spec:
  containers:
  - name: my-container
    image: my-image

*   不推荐使用 Pod 级别的 PSS 标签，因为这会增加 Pod 配置的复杂性，并可能导致策略不一致。

4. 测试和验证

在应用 PSS 级别后，需要进行充分的测试和验证，确保 Pod 能够正常运行，并且安全策略能够有效执行。可以尝试创建或更新一些 Pod，观察是否符合 PSS 级别的要求。

5. 移除 PSP

在确认 PSS 能够满足安全需求后，可以逐步移除 PSP。建议先在非生产环境中移除 PSP，观察一段时间，确认没有问题后再在生产环境中移除。

最佳实践

• 从 Baseline 级别开始：建议从 Baseline 级别开始，逐步收紧安全策略。这可以避免因过于严格的安全策略而导致 Pod 无法正常运行。
• 使用命名空间级别的 PSS：尽可能使用命名空间级别的 PSS，避免在 Pod 级别设置安全级别。这可以简化 Pod 配置，并提高策略一致性。
• 结合其他安全工具：PSS 只是 Kubernetes 安全体系的一部分，可以结合其他安全工具，例如网络策略、镜像扫描等，构建更完善的安全防护体系。
• 持续监控和审计：定期监控和审计 Kubernetes 集群的安全状况，及时发现和解决安全问题。

自定义准入控制器

如果 PSS 无法完全满足安全需求，可以考虑自定义准入控制器。准入控制器是一种 Kubernetes 插件，可以在 Pod 创建或更新时进行自定义的安全检查。通过编写准入控制器，可以实现更精细的安全控制。

自定义准入控制器的优点

• 高度定制化：可以根据实际需求编写自定义的安全检查逻辑，实现高度定制化的安全策略。
• 灵活性：可以动态调整安全策略，适应快速变化的业务需求。

自定义准入控制器的缺点

• 开发成本高：需要编写代码实现安全检查逻辑，开发成本较高。
• 维护成本高：需要定期维护和更新准入控制器，以适应 Kubernetes 的版本更新和安全漏洞修复。
• 风险较高：如果准入控制器存在漏洞，可能会导致安全策略失效。

总结

Pod 安全标准（PSS）是 Kubernetes 官方推荐的安全策略方案，可以有效替代 Pod 安全策略（PSP）。从 PSP 迁移到 PSS 需要仔细评估现有的安全策略，选择合适的 PSS 级别，并进行充分的测试和验证。如果 PSS 无法完全满足安全需求，可以考虑自定义准入控制器。通过合理选择和配置安全策略，可以有效保护 Kubernetes 集群的安全。

希望本文能够帮助你更好地理解 PSP 和 PSS，并顺利完成安全策略的迁移。