Kubernetes yaml的服务器端验证

我想在应用Kubernetes yaml文件之前在服务器端进行验证。

我知道在我的Jenkins代理中，我可以使用以下kubectl命令在服务器端验证yaml文件，但我有点担心访问控制：

Kubernetes文档中的内容如下：

空运行和非空运行请求的授权是相同的。从而，要进行空运行请求，必须授权用户进行非空运行请求。

我不希望任何Jenkins代理商对我的EKS集群拥有超能力。坏演员可能会恶意使用我的Jenkins代理并应用他们想要的任何清单。现在出于安全/稳定/管理的原因，创建Kubernetes对象是由其他系统（而不是Jenkins）完成的。

我检查了其他几个选项，但我看到了缺点：

Kubeval不了解实际群集中安装的任何CRD。
客户端验证不是真正的端到端验证
我可以开发一个REST API，该API公开一个验证REST端点并使用Kubernetes API或在后台运行一个kubectl --run-dry。但是，这需要比我们有能力进行更多的开发工作。

您是否有任何想法，或者您知道我可以在CI系统中安全使用的任何验证工具，用于验证end-2end Kubernetes yaml文件？

我一直在寻找自己的东西，但找不到足够的工具。但是，解决方法很少：

将所有对象部署到dev / stage集群中的临时 ci-job-id名称空间。它们应与产品相同，但不会强加您提到的安全风险。这带来了额外的好处-您可以检查是否所有内容都已创建，所有吊舱都在运行。它有助于发现资源请求不足，图像丢失，Service选择器配置错误等问题。另外，还可以在顶部添加烟雾测试。
旋转一个带有所有CRD的小型迷你库，专门用于CI验证。这种方法可减少覆盖范围，但维护成本却低得多。

不幸的是，我最初想做的事不可行。无法对包含具有依赖项的对象（例如命名空间和Deployment）的清单应用服务器端验证。请参阅this问题。

因此，客户端验证是向前发展的解决方案。它可以使用Kubeval或任何其他客户端机制。 Kubeval不会验证CRD，但可以忽略它们，以使验证不会失败：

当前，kubeval依赖于Kubernetes API生成的模式。这意味着不可能使用CRD验证资源。目前，您需要传递一个标志来忽略丢失的模式这可能会在将来的主要版本中更改。

客户端验证（使用 kubectl --dry-run）几乎没有价值，因为它缺少一些琐碎的 schema misconfigurations。

如果您使用 kubeval 执行验证（正如您提到的，您可以跳过 CRD）或者您可以使用具有 {{3 }}。