奔驰团队的Kubernetes安全策略迁移之旅

在KubeCon EU上，奔驰团队分享了他们从Pod Security Policies（PSP）迁移到Validation Admission Policies（VAP）的过程，以保护其1000多个Kubernetes集群的安全。团队最终选择了VAP而非Kyverno，主要原因是VAP在性能上有显著提升。

初始架构与问题

奔驰的平台最初设计为“自助服务”模式，开发团队可以按需创建或销毁Kubernetes集群，而无需考虑底层操作。最初的集群实现使用PSP来在运行时强制执行安全策略，并通过Open Policy Agent（OPA）与验证和授权Webhook结合来保护Kubernetes API服务器的请求。然而，团队认为这种“一体化”解决方案复杂且容易出错。

对自定义准入策略的需求

团队对自定义准入策略提出了几项需求：

• 必须能够灵活定义多种资源（如Deployments、CronJobs等）的策略，而不仅限于Pod。
• 允许客户无缝使用所需工具，并支持资源突变，因为Kubernetes的默认设置往往不够安全（例如，Pod的allowPrivilegeEscalation默认为true）。

Kyverno的尝试与放弃

团队最初尝试了CNCF孵化项目Kyverno，但由于其API请求响应时间长达11秒，比现有方案慢20倍，因此决定放弃。尽管Kyverno的开发者体验良好，但性能问题使其无法满足需求。不过，在团队分享了性能基准后，Kyverno在1.12.0版本中有所改进。

迁移策略与VAP的发现

团队决定从Kubernetes 1.24迁移到1.25，再升级到1.26，并在迁移过程中发现了VAP这一“圣杯”功能。VAP允许自定义准入逻辑，并通过内存中的抽象语法树（AST）提升性能，且无需额外的控制器。VAP的验证表达式使用Common Expression Language（CEL），这是一种为关键代码路径设计的高性能编程语言。

复杂策略的挑战与解决方案

团队发现，复杂策略容易变得难以阅读，因此他们转而通过简单的Helm设置生成策略。此外，突变需求通过自定义控制器实现。团队提到，Kubernetes 1.31可能会引入类似VAP的突变准入功能。

不同Kubernetes版本的实现

由于VAP仅在Kubernetes 1.26中作为Alpha功能发布，团队在不同版本中使用了不同的实现：

• 对于Kubernetes 1.25，使用OPA和准入控制器进行验证和突变。
• 对于Kubernetes 1.26，使用VAP进行验证，并使用准入控制器进行突变。

性能测试与结论

在Kyverno 1.12.0发布后，团队重新进行了性能测试，并指出Kyverno目前支持VAP生成。团队总结了几点经验：

1. 策略基准测试和端到端测试套件可以确保快速迭代而不牺牲性能或质量。
2. 维护子资源（如Pod或临时容器）时需特别注意，尤其是在实现自定义控制器时。
3. Kubernetes原生策略实现是可行的，尽管作为早期采用者可能会面临一些挑战。

附注：VAP在Kubernetes 1.28中达到Beta状态。