从 Pod 安全策略迁移：综合指南（第 1 部分：过渡到 PSA）

介绍

随着 Kubernetes 作为领先的容器编排平台不断成熟，安全性仍然是部署容器化应用程序的组织最关心的问题。在 Kubernetes 安全工具库中的基础工具中， Pod 安全策略 (PSP)曾经发挥过举足轻重的作用。 PSP 允许管理员精心定义和实施对 Pod 的安全约束，确保只有满足特定安全标准的容器才能在集群中运行。

然而，Kubernetes 安全形势正在迅速发展，值得注意的是，从 Kubernetes 1.25 开始，PSP 现已被弃用（请参阅 Kubernetes 1.25 紧急发行说明的链接）。这种变化源于多种因素，包括管理和维护 PSP 策略的复杂性，通常会给用户带来操作挑战。

为了应对弃用，组织现在正在寻找 PSP 的现代替代方案，这些替代方案不仅可以满足安全要求，还可以简化保护Kubernetes中工作负载的过程。

在这份综合指南中，我们踏上了驾驭 Kubernetes 安全实践这一转变的旅程，重点关注向 Pod 安全准入 (PSA) 的过渡。 PSA 是最强大的替代方案之一，本文将对其进行深入探讨。然而，值得一提的是，另外两个替代方案 Kyverno 和 OPA Gatekeeper 将在本系列的单独文章中介绍。

在本文中，您将找到有关设置和安装 PSA 的详细说明、从 PSP 顺利过渡到 PSA 的分步迁移指南，以及将现有 PSP 规则转移到 PSA 的精确命令。此外，您还将获得使用专为 PSA 定制的空运行命令来评估命名空间的迁移准备情况的知识。

读完本指南后，您将全面了解 PSA 的优势和局限性，使您能够根据组织的特定安全要求和 Kubernetes 环境做出明智的决策。

借助本指南，您可以自信地实现 Kubernetes 安全实践的现代化，确保您的工作负载在告别 Pod 安全策略时代时仍然受到保护。

吊舱安全入场 (PSA)

• PSA 执行 Kubernetes 安全标准： PSA 确保容器遵守 Kubernetes 的本机安全标准，这些标准由 Pod 安全标准定义。这些标准将安全策略分为三个不同的配置文件，每个配置文件都有不同的限制级别：

  
  

  • 特权：特权政策是有意开放且完全不受限制的。通常，此策略针对由受信任用户管理的系统和基础设施级工作负载。它的特点是没有限制。虽然像 Gatekeeper 这样的默认允许机制本质上可能是特权的，但对于像 Pod 安全策略 (PSP) 这样的默认拒绝机制，特权策略应该停用所有限制。

  • 基线：基线策略旨在方便常见容器化工作负载采用，同时防止已知的权限升级。它面向应用程序运营商和非关键应用程序开发人员。

  • Restricted ：Restricted 策略的重点是执行严格的 Pod 强化最佳实践，尽管可能会牺牲一些兼容性。它主要针对安全关键应用程序的运营商和开发人员，以及信任度较低的用户。有关每个配置文件下应强制执行或禁止的控制的完整列表，您可以参阅官方文档。

    
    

• 无直接 PSP 规则传输：与其他一些解决方案不同，PSA 不提供直接迁移或修改 Pod 安全策略 (PSP) 规则的简单方法。 PSA 的主要重点是根据既定的Kubernetes 安全标准（包括上述配置文件）验证 pod。

• 无突变：虽然 PSA 在验证方面很有效，但它无法像 PSP 那样修改或自定义 pod 规格。 PSA 的主要目的是执行预定义的 Kubernetes 安全标准，不包括更改或改变 pod 规格的功能。它主要侧重于根据这些既定标准验证 Pod。

设置和安装

由于 PSA 是 Kubernetes 本机组件，要使其正常工作，您只需确保 Kubernetes 集群中启用了 Pod 安全准入 (PSA) 控制器。您可以通过运行以下命令来做到这一点：

kubectl api-versions | grep admission

迁移的准备步骤

评估命名空间权限

Pod 安全准入的控制受命名空间标签的影响。这意味着能够更新、修补或创建命名空间的个人也有权修改这些命名空间的 Pod 安全设置。此修改可能会绕过更严格的安全策略。在继续之前，必须验证命名空间权限是否专门分配给受信任的特权用户。建议不要向不需要此类访问权限的用户授予这些提升的权限。如果在命名空间对象上配置 Pod 安全标签时需要额外的限制，请考虑使用准入 Webhook 来强制实施这些限制。

简化和规范 PodSecurityPolicies

在迁移到 Pod Security Entry (PSA) 之前，规范化您的 PodSecurityPolicies (PSP) 是有好处的：

• 删除不支持的字段：删除 Pod 安全标准未涵盖的选项。这些选项包括：

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• 消除纯粹变异的字段：通过删除仅具有变异作用且不影响验证策略的字段来启动该过程。正如“将 PodSecurityPolicies 映射到 Pod 安全标准”参考中也提到的，这些字段包括：

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

确定合适的 Pod 安全级别

在为您的命名空间确定适当的 Pod 安全级别时，您可以考虑多种方法：

按命名空间的安全要求

如果您熟悉命名空间的预期访问级别和安全要求，则可以根据这些特定要求选择合适的 Pod 安全级别。此方法类似于在新集群中处理安全设置的方式。

通过现有的 PodSecurityPolicies：

利用“将 PodSecurityPolicies 映射到 Pod 安全标准”参考将每个现有 Pod 安全策略 (PSP) 映射到相应的 Pod 安全标准级别。
如果您的 PSP 最初并非基于 Pod 安全标准，您可能需要做出决定。选择至少与 PSP 一样宽松的 Pod 安全级别，或者选择至少与 PSP 一样严格的级别。要确定特定命名空间内的 pod 正在使用哪些 PSP，请使用以下命令：

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

通过现有 Pod：

进行试运行并应用下一节中的标签命令来测试基线和受限 Pod 安全级别。这有助于您评估这些级别是否足以满足您现有的工作负载。选择与您现有工作负载相符的最低特权有效级别。

测试 Pod 安全级别

确定命名空间的 Pod 安全级别（特权级别除外）后，验证所选策略非常重要。 Pod Security 提供测试选项，以确保顺利部署并符合安全标准。

试运行测试：

使用此方法可以评估所选策略的影响，而无需立即执行。
要执行试运行，请使用以下命令，该命令将突出显示任何不符合指定策略级别的现有 Pod：

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

审核模式测试：

审核模式允许您记录策略违规行为而不强制执行。违规的 Pod 会记录在审核记录中以供日后审核。使用以下命令启用审核模式：

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

如果测试过程中出现意外的策略违规，您可以：

• 更新不合规的工作负载以符合策略。
• 如有必要，请调整命名空间的 Pod 安全级别以满足您的工作负载要求。

强制 Pod 安全级别

一旦您确信所选的 Pod 安全级别适合您的命名空间，您就可以继续强制执行它。此步骤可确保所需的安全标准主动应用于命名空间内的工作负载。

要在命名空间上强制执行所需的 Pod 安全级别，请使用以下命令：

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

执行此命令将激活并强制执行指定的 Pod 安全级别，从而增强命名空间的安全状况。

绕过PSP

要在命名空间级别有效绕过 PodSecurityPolicy，您可以将完全特权的 Pod 安全策略 (PSP) 绑定到命名空间中的所有服务帐户。此过程可确保命名空间内的 pod 不再受到 PodSecurityPolicy 施加的修改或限制。您可以在集群级别或单个命名空间级别执行此操作。

集群范围的设置（整个集群只需要一次）：

通过应用 YAML 配置文件（例如privileged-psp.yaml ）创建完全特权的 Pod 安全策略 (PSP)。此 PSP 应向 pod 授予所有必要的权限，并创建一个名为privileged-psp 的集群角色，以允许使用 Pod 安全策略 (PSP) 并将其与特权 PSP 关联：

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

每个命名空间禁用：

在目标命名空间中创建角色绑定，以将特权-psp 集群角色与system:serviceaccounts:$NAMESPACE组关联。此绑定有效地授予命名空间内的所有服务帐户对完全特权 PSP 的访问权限，绕过 PodSecurityPolicy：

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

通过此设置，特权 PSP 不会发生变化，并且 PodSecurityPolicy 准入控制器始终优先考虑不会发生变化的 PSP。因此，该命名空间中的 pod 将不再被 PodSecurityPolicy 修改或限制。

这种方法的优点之一是其可逆性。如果出现任何问题，您可以通过删除与禁用 PodSecurityPolicy 关联的 RoleBinding 来轻松回滚更改。确保在此过程中预先存在的 Pod 安全策略保持不变。

撤消 PodSecurityPolicy 禁用：

要恢复命名空间的 PodSecurityPolicy 禁用，只需删除之前创建的 RoleBinding 即可：

 kubectl delete -n $NAMESPACE rolebinding disable-psp

重新审视命名空间创建过程

更新现有命名空间以强制执行 Pod 安全准入后，必须检查和更新创建新命名空间的流程和策略。这确保从一开始就使用适当的 Pod 安全配置文件配置新的命名空间。
请考虑以下步骤来增强命名空间创建过程：

1. 调整命名空间创建策略：更新组织用于创建新命名空间的策略和过程，以包括所需 Pod 安全级别的选择和应用。确保从创建阶段就制定安全标准。

2. 静态配置：您可以静态配置 Pod 安全准入控制器，为未标记的命名空间定义默认强制、审核和/或警告级别。此方法可确保缺少显式 Pod 安全标签的命名空间默认情况下仍符合您指定的安全标准。

   
   

   通过重新审视命名空间创建过程，您可以将 Pod 安全标准无缝集成到Kubernetes 环境中，并在所有新旧命名空间中保持一致且安全的方法。

禁用 PodSecurityPolicy

一旦您确信不再需要 PodSecurityPolicy (PSP) 准入控制器并且 Pod 安全准入 (PSA) 已成功实施和验证，您可以继续禁用 PSP 准入控制器。

以下是禁用 PSP 准入控制器的步骤：

修改 kube-apiserver 配置：

• 打开 kube-apiserver 的配置文件，通常位于/etc/kubernetes/manifests/kube-apiserver.yaml.
• 添加--disable-admission-plugins标志以禁用 PSP 准入控制器。确保它已从活动准入插件列表中删除。

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• 保存配置文件。

重启 kube-apiserver：

• 重新启动 kube-apiserver 以应用更改。通常可以通过重新启动 Kubernetes 控制平面或 kube-apiserver pod 本身来实现此目的。

 systemctl restart kubelet

确认：

• 通过检查 kube-apiserver 日志或其状态，确保 PSP 准入控制器已禁用。

经过足够的“浸泡时间”以确信您不需要回滚到 PSP 后，继续下一步。

清理 PSP 资源：

禁用 PSP 准入控制器并就位 PSA 后，您可以安全地删除现有的 PodSecurityPolicies 以及任何关联的 Roles、ClusterRoles、RoleBindings 和 ClusterRoleBindings。

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

此清理步骤可确保集群中没有残留的 PSP 配置。

通过停用 PSP 准入控制器并消除 PSP 相关资源，您可以简化集群的安全架构，完成向 Pod 安全准入的过渡。

概括

在这份综合指南中，我们探讨了将 Kubernetes 集群的安全框架从 Pod 安全策略 (PSP) 顺利过渡到 Pod 安全准入 (PSA) 的基本步骤和注意事项。此迁移可确保您的工作负载继续安全运行，同时符合 Kubernetes 不断发展的安全标准。

使用 Pod 安全准入 (PSA) 的优点和缺点

优点：

• 原生 Kubernetes 组件：PSA 是 Kubernetes 不可或缺的一部分，无需安装第三方工具。它利用平台的内置安全功能。
• 执行 Kubernetes 标准：PSA 与 Kubernetes 的本机安全标准保持一致，确保符合平台的最佳实践。

缺点：

• 有限的定制：PSA 可能无法提供与 PSP 相同级别的定制，特别是对于需要改变 pod 规格的复杂安全策略。
• 需要改造：必须更新现有工作负载以包含安全上下文设置，这可能需要修改 YAML 文件。

本指南为您提供自信地从 PSP 迁移到 PSA 所需的知识和步骤，确保安全高效的迁移，同时保护您的 Kubernetes 工作负载。请继续关注即将发布的文章，我将在其中探索 Kyverno 和 OPA Gatekeeper 的替代迁移路径。