K8s Pod Security Admission (PSA) 替代 PSP 的最佳实践

好的，各位观众老爷们，掌声在哪里！🎉 今天咱们不聊高并发，也不谈微服务，而是聚焦一个K8s里的小可爱，但又非常重要的话题——Pod Security Admission（PSA），以及如何优雅地送走它的老朋友 Pod Security Policy（PSP）。

PSP，这位曾经的卫士，守护着我们的Pod安全，但它复杂的配置和难以管理的特性，让很多小伙伴头疼不已。现在，英雄迟暮，PSA带着更简洁、更灵活的姿态闪亮登场，准备接过PSP的接力棒。

那么，问题来了：如何才能平稳过渡，让我们的集群从PSP丝滑切换到PSA？别急，听我慢慢道来，保证你听得津津有味，学得明明白白！

一、PSP：曾经的辉煌与无奈

首先，让我们缅怀一下PSP，这位曾经的功臣。PSP允许我们定义Pod的安全策略，例如限制容器的用户ID、禁止特权模式、限制capabilities等等。有了PSP，我们可以有效防止恶意Pod对集群造成破坏。

举个例子，我们可能定义一个PSP，禁止Pod使用HostNetwork，以防止Pod绕过K8s的网络隔离：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: no-host-network
spec:
  hostNetwork: false
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - configMap
  - emptyDir
  - projected
  - secret
  readOnlyRootFilesystem: true

这个PSP很简单，禁止Pod使用HostNetwork，并且强制Pod以非特权模式运行。但是，PSP的缺陷也逐渐暴露出来：

配置复杂： PSP的配置项非常多，学习成本高，容易出错。
难以管理： PSP与ServiceAccount的绑定关系复杂，容易导致授权混乱。
调试困难： 当Pod被PSP拒绝时，错误信息不够友好，难以定位问题。
迭代缓慢： PSP的API更新缓慢，无法跟上K8s的发展步伐。

总而言之，PSP就像一位经验丰富的老管家，虽然尽职尽责，但过于保守和固执，难以适应快速变化的时代。

二、PSA：新时代的守护者

PSA，全称Pod Security Admission，是K8s官方推出的替代PSP的新方案。它基于Pod Security Standards（PSS），定义了三个安全级别：

Privileged： 无限制策略，允许所有操作。
Baseline： 最小化策略，阻止已知的特权提升。
Restricted： 严格策略，遵循Pod强化最佳实践。

这三个级别从宽松到严格，覆盖了不同的安全需求。你可以根据实际情况，为不同的Namespace选择合适的安全级别。

PSA的优势显而易见：

配置简单： PSA基于PSS，配置简单易懂，上手容易。
管理方便： PSA与Namespace绑定，管理方便，易于维护。
调试友好： 当Pod被PSA拒绝时，错误信息清晰明了，方便定位问题。
迭代迅速： PSA是K8s内置特性，更新迅速，紧跟K8s的发展步伐。

PSA就像一位年轻有为的管家，思维灵活，善于学习，能够更好地满足现代集群的安全需求。

三、从PSP到PSA：平滑过渡的最佳实践

现在，我们进入正题：如何才能平稳地从PSP切换到PSA？这可不是一蹴而就的事情，需要周密的计划和细致的执行。下面，我将分享一些最佳实践，助你轻松完成过渡。

1. 了解你的PSP策略

在迁移之前，首先要彻底了解你现有的PSP策略。你需要知道：

哪些PSP正在使用？
这些PSP限制了哪些操作？
哪些ServiceAccount绑定了这些PSP？
哪些Pod受到这些PSP的影响？

你可以使用kubectl命令来查看PSP的配置：

kubectl get podsecuritypolicy
kubectl describe podsecuritypolicy <psp-name>

同时，你还需要分析你的应用，了解它们的实际安全需求。哪些应用需要特权模式？哪些应用需要访问HostNetwork？哪些应用需要特定的capabilities？

表格：PSP策略分析示例

PSP Name	限制操作	绑定ServiceAccount	影响的Pod	备注
no-host-network	禁止HostNetwork	default	nginx-deployment-xxxx	阻止Pod使用HostNetwork
restricted-psp	限制capabilities、用户ID	backend	backend-deployment-yyyy	遵循Pod强化最佳实践
privileged-psp	无限制	kube-system	kube-proxy-xxxx	允许所有操作

2. 评估PSS安全级别

了解了PSP策略之后，你需要评估PSS的三个安全级别是否能够满足你的需求。

Privileged： 如果你的应用需要完全的权限，例如kube-proxy，那么Privileged级别是合适的。
Baseline： 如果你的应用需要一些基本的安全限制，例如禁止特权模式，那么Baseline级别是合适的。
Restricted： 如果你的应用需要遵循Pod强化最佳实践，那么Restricted级别是合适的。

你可以参考K8s官方文档，了解每个安全级别的具体限制。

3. 启用PSA的Dry-run模式

在正式启用PSA之前，强烈建议你先启用Dry-run模式。Dry-run模式可以模拟PSA的执行，但不会实际阻止Pod的创建。

你可以通过以下方式启用Dry-run模式：

Namespace Label： 在Namespace上添加pod-security.kubernetes.io/enforce: audit标签。
kube-apiserver Flag： 在kube-apiserver的启动参数中添加--admission-control-config-file，指定一个包含Dry-run配置的文件。

Dry-run模式会将PSA的评估结果记录到Audit Log中。你可以通过分析Audit Log，了解哪些Pod会被PSA拒绝，并及时调整你的配置。

4. 逐步迁移Namespace

不要一次性将所有Namespace都迁移到PSA。建议你采取逐步迁移的策略，先从测试环境开始，然后逐步推广到生产环境。

第一步： 在测试环境的Namespace上启用Dry-run模式，观察Audit Log，调整配置。
第二步： 在测试环境的Namespace上启用Enforce模式，验证PSA是否正常工作。
第三步： 在生产环境的Namespace上启用Dry-run模式，观察Audit Log，调整配置。
第四步： 在生产环境的Namespace上启用Enforce模式，完成迁移。

5. 禁用PSP

在确认所有Namespace都成功迁移到PSA之后，你可以禁用PSP。

你可以通过以下方式禁用PSP：

删除PSP资源： 删除所有PodSecurityPolicy资源。
移除Admission Controller： 从kube-apiserver的启动参数中移除PodSecurityPolicy admission controller。

警告： 在禁用PSP之前，务必确保所有Namespace都已成功迁移到PSA，否则可能会导致Pod无法创建。

四、PSA的配置方法

PSA的配置主要通过Namespace Label来实现。你可以在Namespace上添加以下标签，来指定PSA的安全级别：

pod-security.kubernetes.io/enforce: <level>：强制执行指定级别的策略。
pod-security.kubernetes.io/audit: <level>：将违反指定级别策略的事件记录到Audit Log中。
pod-security.kubernetes.io/warn: <level>：在客户端显示违反指定级别策略的警告信息。

其中，<level>可以是privileged、baseline或restricted。

例如，如果你想在一个Namespace上强制执行Baseline级别的策略，可以将以下标签添加到该Namespace：

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

五、一些实用的技巧与注意事项

利用OPA Gatekeeper进行增强： PSA虽然简单易用，但功能相对有限。如果你需要更复杂的安全策略，可以考虑结合OPA Gatekeeper使用。 OPA Gatekeeper可以让你自定义安全策略，并将其应用到集群中的所有资源。
关注K8s版本更新： PSA是K8s内置特性，会随着K8s版本的更新而不断改进。建议你关注K8s的官方文档，了解PSA的最新特性和最佳实践。
编写自动化测试： 为了确保PSA的配置正确有效，建议你编写自动化测试，定期检查集群的安全状态。
充分利用Audit Log： Audit Log是排查PSA问题的利器。当Pod被PSA拒绝时，可以查看Audit Log，了解具体的错误信息。
循序渐进，不要操之过急： 从PSP到PSA的迁移是一个循序渐进的过程。不要操之过急，一步一个脚印，才能确保迁移的顺利完成。

六、一个完整的迁移案例

假设我们有一个集群，其中使用了一个名为restricted-psp的PSP，限制了Pod的capabilities。现在，我们想将该集群迁移到PSA，并使用Restricted级别的策略。

1. 分析restricted-psp：

kubectl describe podsecuritypolicy restricted-psp

通过分析restricted-psp的配置，我们了解到它禁止了Pod使用NET_ADMIN capability。

2. 评估PSS安全级别：

Restricted级别的策略也禁止Pod使用NET_ADMIN capability，因此可以满足我们的需求。

3. 在测试环境启用Dry-run模式：

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
  labels:
    pod-security.kubernetes.io/enforce: audit
    pod-security.kubernetes.io/enforce-version: v1.28 # 替换为你的K8s版本

4. 观察Audit Log：

创建一些Pod，观察Audit Log，确认没有Pod被Restricted级别的策略拒绝。

5. 在测试环境启用Enforce模式：

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28 # 替换为你的K8s版本

6. 在生产环境重复上述步骤：

7. 禁用PSP：

删除restricted-psp资源，并从kube-apiserver的启动参数中移除PodSecurityPolicy admission controller。

七、总结：拥抱更安全的未来

从PSP到PSA的迁移，是K8s安全体系的一次重要升级。 PSA以其简洁、灵活的特性，将更好地守护我们的集群安全。

记住，迁移不是一蹴而就的事情，需要周密的计划和细致的执行。只要你掌握了正确的姿势，就能轻松完成过渡，拥抱更安全的未来。

希望这篇文章能帮助你更好地理解PSA，并顺利完成从PSP到PSA的迁移。祝你玩转K8s，安全无忧！ 🚀

最后，别忘了点个赞，转发一下，让更多的小伙伴受益！ 😉

发表回复 取消回复

发表回复取消回复