WEBKT

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

45 0 0 0

PSP:曾经的安全卫士

PSS:新的安全标准

PSP 与 PSS 的对比

从 PSP 迁移到 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。以下是从 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,并顺利完成安全策略的迁移。

K8s安全卫士 Kubernetes 安全Pod 安全标准Pod 安全策略

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9784