Kubernetes yaml 的服务器端验证
Server-side Validation of Kubernetes yaml
我想在应用之前对 Kubernetes yaml 文件进行服务器端验证。
我知道在我的 Jenkins 代理中，我可以使用以下 kubectl 命令在服务器端验证 yaml 文件，但我有点担心访问控制：
- Kubernetes < v1.18:
kubectl apply --server-dry-run -f ...
- Kubernetes >= v1.18：
kubectl apply --dry-run=server -f ...
Kubernetes 文档说明如下：
Authorization for dry-run and non-dry-run requests is identical. Thus,
to make a dry-run request, the user must be authorized to make the
non-dry-run request.
我不希望任何 Jenkins 代理对我的 EKS 集群拥有超级权力。坏人可以恶意使用我的 Jenkins 代理并应用他们想要的任何清单。现在由于 security/stability/management 个原因，创建 Kubernetes 对象是由另一个系统而不是 Jenkins 完成的。
我检查了其他几个选项，但我看到了缺点：
- Kubeval 不知道实际集群中安装了任何 CRD。
- 客户端验证并不是真正的端到端验证
- 我可以开发一个 rest api 来公开验证 rest 端点并访问 Kubernetes API 或在后台运行 kubectl
--run-dry。然而，这需要比我们能力更多的开发工作。
您有什么想法或者您知道我可以在我们的 CI 系统中安全地使用任何验证工具来验证端到端 Kubernetes yaml 文件吗？
我自己一直在寻找这个，但没有找到足够的工具。但是，几乎没有解决方法：
- 将所有对象部署到 dev/stage 集群中的 临时
ci-job-id 命名空间。它们应该与产品相同，但不会强加您提到的安全风险。这提供了一个额外的好处——您可以检查是否所有内容都已创建，所有 pods 都是 运行。它有助于捕获资源请求不足、图像丢失、配置错误 Service 选择器等问题。此外，它还允许您在顶部添加冒烟测试。
- 使用所有专门用于 CI 验证的 CRD 旋转一个小型 minikube。这种方法的覆盖范围较小，但维护成本要低得多。
很遗憾，我最初想做的事情是行不通的。无法对包含具有依赖性的对象（例如命名空间和部署）的清单应用 server-side 验证。请参阅 this 问题。
因此，客户端验证是向前发展的解决方案。它要么与 Kubeval 一起使用，要么与任何其他 client-side 机制一起使用。 Kubeval 不会验证 CRD，但可以忽略它们，这样验证就不会失败：
Currently kubeval relies on schemas generated from the Kubernetes API.
This means it's not possible to validate resources using CRDs.
Currently you need to pass a flag to ignore missing schemas, though
this may change in a future major version.
客户端验证（使用 kubectl --dry-run）没有什么价值，因为它缺少一些琐碎的 schema misconfigurations。
如果您使用 kubeval 执行验证（正如您提到的，您可以跳过 CRD）或者您可以使用 kubeconform 有 CRD support.
我想在应用之前对 Kubernetes yaml 文件进行服务器端验证。
我知道在我的 Jenkins 代理中，我可以使用以下 kubectl 命令在服务器端验证 yaml 文件，但我有点担心访问控制：
- Kubernetes < v1.18:
kubectl apply --server-dry-run -f ... - Kubernetes >= v1.18：
kubectl apply --dry-run=server -f ...
Kubernetes 文档说明如下：
Authorization for dry-run and non-dry-run requests is identical. Thus, to make a dry-run request, the user must be authorized to make the non-dry-run request.
我不希望任何 Jenkins 代理对我的 EKS 集群拥有超级权力。坏人可以恶意使用我的 Jenkins 代理并应用他们想要的任何清单。现在由于 security/stability/management 个原因，创建 Kubernetes 对象是由另一个系统而不是 Jenkins 完成的。
我检查了其他几个选项，但我看到了缺点：
- Kubeval 不知道实际集群中安装了任何 CRD。
- 客户端验证并不是真正的端到端验证
- 我可以开发一个 rest api 来公开验证 rest 端点并访问 Kubernetes API 或在后台运行 kubectl
--run-dry。然而，这需要比我们能力更多的开发工作。
您有什么想法或者您知道我可以在我们的 CI 系统中安全地使用任何验证工具来验证端到端 Kubernetes yaml 文件吗？
我自己一直在寻找这个，但没有找到足够的工具。但是，几乎没有解决方法：
- 将所有对象部署到 dev/stage 集群中的 临时
ci-job-id命名空间。它们应该与产品相同，但不会强加您提到的安全风险。这提供了一个额外的好处——您可以检查是否所有内容都已创建，所有 pods 都是 运行。它有助于捕获资源请求不足、图像丢失、配置错误Service选择器等问题。此外，它还允许您在顶部添加冒烟测试。 - 使用所有专门用于 CI 验证的 CRD 旋转一个小型 minikube。这种方法的覆盖范围较小，但维护成本要低得多。
很遗憾，我最初想做的事情是行不通的。无法对包含具有依赖性的对象（例如命名空间和部署）的清单应用 server-side 验证。请参阅 this 问题。
因此，客户端验证是向前发展的解决方案。它要么与 Kubeval 一起使用，要么与任何其他 client-side 机制一起使用。 Kubeval 不会验证 CRD，但可以忽略它们，这样验证就不会失败：
Currently kubeval relies on schemas generated from the Kubernetes API. This means it's not possible to validate resources using CRDs. Currently you need to pass a flag to ignore missing schemas, though this may change in a future major version.
客户端验证（使用 kubectl --dry-run）没有什么价值，因为它缺少一些琐碎的 schema misconfigurations。
如果您使用 kubeval 执行验证（正如您提到的，您可以跳过 CRD）或者您可以使用 kubeconform 有 CRD support.