如何验证 Kubernetes YAML 文件

原文出自：Armo’s blog 原文作者：Bezalel Brandwinen,，Team Lead at Armo Ltd

Kubernetes 在我们现在如何管理容器化应用程序方面占据了中心位置。因此，存在许多定义我们的 的协议，包括 、JSON、INI 等结构。

这使得我们会去考虑，什么是我们的应用程序应遵循的最佳策略。此外，我们还必须清楚，如何根据我们在文件结构，特别是安全性方面，选择路径来验证我们的应用程序配置。

在本文中，我们将探索如何使用 YAML 配置定义 Kubernetes 应用程序，以及哪些是我们可以采取的步骤，来有效验证这些配置定义。

YAML 中的 Kubernetes 配置定义

与 JSON 和 INI 相比， YAML更加紧凑和可读。比如我们定义一个80端口可以访问的pod，那么YAML、JSON、INI中的配置如下表所示：

很明显，YAML 简化了我们定义 Kubernetes 应用程序的方式，特别是考虑到一个普通的应用程序可能涉及数十个配置文件。此外，YAML 的紧凑特性允许您将对象组合在一起，从而减少所需文件的数量。

但是，定义我们的 Kubernetes 配置文件存在重大挑战，尤其是在尝试在清单文件之间嵌入约束和关系时。例如，我们如何确保内存限制配置为遵循最佳实践？

当遇到边缘情况时，缺乏验证不仅会导致我们的应用程序出现意外，而且还会暴露主要的安全漏洞。因此，我们有必要考虑基于 YAML 的配置文件的验证策略，这就是我们将在以下部分中深入探讨的内容。

验证的各个方面

应该对我们的 YAML 文件执行三个级别的验证。这些级别确保根据 YAML 文件的实际有效性执行验证，一直到是否满足安全实践。

第一级是结构验证，这是对 Kubernetes 配置文件进行的最高级别的验证。它涉及简单地验证 YAML 文件，以确保在编写它时没有语法错误。这是编写配置文件时使用的 IDE 可以验证的内容。

第二层是语义验证，这确保 YAML 文件的内容转换为所需的 Kubernetes 资源，从而验证 Kubernetes 应用程序本身。

第三个是最深层次的验证，安全验证， 以确保定义的 Kubernetes 应用程序没有任何漏洞。我们可能已经成功地编写了 以成功实现所需的 Kubernetes 资源和连接，但这并不能确保我们的 Kubernetes 应用程序得到很好的保护并遵循最佳实践。上面最后两个验证都是Kubernetes配置验证，并不仅仅在方面。由于它们是特定于应用程序的验证，因此专门的诊断是必要的。执行此类验证需要 Kubernetes 领域的深入专业知识，我们将简要介绍如何使用 Kubernetes 领域专家开发的工具轻松处理它们。

例如，锁定 hostPath 挂载权限可确保集群中具有可写 hostPath 卷的容器不会被攻击者访问，因为他们可能会在底层主机上获得持久性。这不符合安全最佳实践，为避免此问题，我们应始终确保将 hostPath 属性下的readOnly 部分设置为 true。

另一个示例是仅在必要时授予 hostNetwork 对 pod 的访问权限。所有具有访问权限的 pod 也应列入白名单。对主机网络的不必要访问增加了潜在的攻击面。

所以，从上面两个例子可以看出，即使我们的配置文件通过了结构和语义验证，促使我们的 Kubernetes 资源被成功编排，但安全和功能漏洞仍然可能存在。因此，我们必须考虑如何最好地捕获这些漏洞，然后再提醒生产中的后果。安全验证是执行此操作的方法。

另一个示例是仅在必要时授予 hostNetwork 对 pod 的访问权限。所有具有访问权限的 pod 也应列入白名单。对主机网络的不必要访问增加了潜在的攻击面。

所以，从上面两个例子可以看出，即使我们的配置文件通过了结构和语义验证，导致我们的 Kubernetes 资源被成功编排，安全和功能漏洞仍然可能存在。因此，我们必须考虑如何最好地捕获这些漏洞，然后再提醒生产中的后果。安全验证是执行此操作的方法。

验证和最佳实践

考虑到结构验证相当简单，可以预期可用的工具目前是可以在您的 IDE 中轻松获得。Kubernetes 语义和安全验证需要更多的努力，尤其是在策略和工具方面。

让我们考虑一些最佳实践和策略，这些实践和策略需要实现对我们的 YAML 文件的整体验证。

始终左移

我们可能总是验证我们的 K8s 配置，即使我们已经使用 Kubescape 等工具将它们部署在集群中，但“左移”总是更好。左移是一个在过去五六年里火了起来的词，这是理所当然的。您希望使验证更接近应用程序的交付和构建阶段。

例如，语义验证是 Kubernetes 本身可以处理的事情。但是，当您将其交给 Kubernetes 处理时，为时已晚。

您可以执行空运行 ( kubectl apply -f --dry-run=‘server’’) 来验证语义结构，但这仍然是一个额外的步骤，可能会降低您的整体速度。但是，试运行需要您有权访问 Kubernetes 集群。

这种方法的替代方法是 Kubeval，这是一个了不起的工具，可用于验证您的配置文件语义以确保它们满足 Kubernetes 的对象定义要求。它可以成为您的 CI 过程的一部分并在本地执行扫描，从而确保您在投入生产之前从语义上验证您的配置文件。

还可以使用 Kubescape在 CI 中实现安全验证。这是一个开源工具，可确保您的 Kubernetes 应用程序定义遵循多个安全框架，例如 NSA-CISA 或 MITRE ATT&CK®。通过使用 Kubescape CLI，您可以扫描所有 YAML 文件以查找安全漏洞，甚至可以获得风险评分和风险趋势。它充当 YAML 验证器 ，其主要价值是安全验证。

DevOps 到 DevSecOps

您可以运行 CI 管道中已经讨论过的工具组合，以实现结构、语义和安全验证。然而，仅使用这些工具及其预定义的检查是不够的。

我们从 DevOps 中学到的一件事是，总有一个可以采用的改进周期。这就是为什么随着您的应用程序的发展和您的安全需求的变化，您应该不断检查您的安全控制。

新的安全控制是您应该纳入安全验证步骤的东西。Kubescape 是 AMRO 的开源平台，允许您定义自己的控件框架。尽管开箱即用的框架非常强大，但您会看到您的策略控制是根据您的业务和 Kubernetes 资源的确切需求而形成的。

只有将安全问题嵌入到您构建应用程序的文化中，才能实现这种做法。多亏了 Kubeval 和 Kubescape 等开源工具，您的开发团队不断思考验证，尤其是安全验证的障碍已经降低。

结论

YAML 配置文件使构建 Kubernetes 应用程序变得非常简单。然而，YAML 在验证方面确实有其局限性。因此，我们有必要了解所有验证策略，以确保我们构建的 Kubernetes 应用程序健康且安全。

在任何 IDE 中使用 YAML 测试验证 YAML 文件的结构都相当简单，但验证 Kubernetes 资源对象定义的正确性和围绕它们的安全措施却很困难。幸运的是，诸如 Kubescape 之类的工具弥补了这一差距，让您可以在整个应用程序生命周期中不断思考安全问题。

由于安全性是当今构建容器化应用程序的主要关注点之一，因此此处讨论的验证策略是朝着正确方向迈出的一步。

---

戳链接，免费获取K8s多云多集群管理解决方案>>