适用于 Kubernetes 1.6 的 CIS 基准测试

互联网安全中心 （CIS） 上周发布了 Kubernetes 1.6 的新 banchmark。随着容器技术的采用迅速增长，编排器已成为关键的推动因素，因为人类无法有效地管理大规模部署。

虽然保护单节点部署非常重要，但保护集群在很大程度上取决于整个编排器配置的安全性。

正如我们在关于 Docker CIS 基准测试的博客中所解释的那样，安全要求的标准化非常重要，因此 CIS 发布编排器标准是合乎逻辑的。Kubernetes 是领先的编排器之一，并得到了 CNCF 的认可。尽管它仍在快速变化，并且其路线图上规划了许多安全功能（我前段时间在 K8S 博客上写过），但 CIS 认为 1.6 版本已经足够成熟，可以创建一个标准的基准文档，以帮助组织在生产中采用 Kubernetes。

CIS 基准测试：您应该了解的

与 Docker CIS 基准测试发布时一样，让我印象深刻的一件事是新基准测试的长度（超过 220 页），请记住，这只是第一个版本！一般来说，编排器，尤其是 Kubernetes，是复杂的多组件系统。保护此类系统并非易事，本文档的范围证明了这一点。

为了帮助您分清谷壳，以下是我认为本文档中从安全角度来看最重要的建议，并按安全措施的类别分组：

设置身份验证和授权

• 请求必须经过授权和“允许”，不允许任何形式的未经授权/未经身份验证的访问。

• 在相关的情况下为集群组件提供单独的身份 （服务帐户）。这允许仅向这些组件提供所需的最低权限。

• 将授权配置为尽可能精细，并特别注意仅在需要时授予管理员角色。

• 应轮换证书和密钥。配置您的集群以启用此类过程。

保护传输中的数据

• 与集群之间以及内部组件之间的所有通信都必须加密和验证，并始终验证组件的证书。

• 必须相应地配置每个集群组件。

保护静态数据

• 未经授权的任何人或任何事物都不得访问敏感数据。相应地设置 ACL 和所有权。

• 由于当前实施带来的风险，请避免使用 Kubernetes 密钥。

• 将不同敏感度级别的数据分开（例如日志和机密）。这允许设置适合敏感度级别的保护措施。

• 所有包含关键配置的文件必须只能由集群管理员写入。必须相应地设置文件 ACL 和所有权。

使用最低权限

“最小权限”原则必须是确保集群安全的指路明灯。通过遵循它，您将最大限度地减少攻击面：

• 通过使用命名空间创建管理边界来最小化用户权限的范围。

• 通过使用网络策略对网络进行分段，最大限度地减少容器的“网络”权限范围。

• 默认情况下，不应运行任何特权容器，并且不应允许用户访问在特权模式下运行的容器。

其他运行时控件

请考虑以下事项：

• 为 Pod 提供身份，即使用单独的服务帐户，而不仅仅是回退到 'default'。这样可以更好地控制和监控您的运行时。

• 配置 Pod 安全策略，然后仅允许运行符合该策略的 Pod。

• 配置由底层平台（seccomp、SELinux 等）和 Kubernetes（安全上下文）提供的安全控制。

• 启用并正确配置事件日志记录。这对于合规性审计和发生安全事件时的取证非常重要。

总结

以上所有内容对某些人来说听起来似乎是显而易见的，但正确配置 Kubernetes 等复杂软件非常具有挑战性。CIS 基准测试是一个令人印象深刻的参考，它利用了当前的 Kubernetes 发布功能，但遵循 106 个不同的项目可能很难确定优先级——我希望读者可以将我的亮点用作遵循 CIS 基准测试的“最佳实践”方法。

拥有保护编排器的新兴标准证明，安全性受到重视，并且市场正在走向成熟。Aqua 将继续挑战极限，使这些标准更易于实施，并超越这些标准，为生产中的关键应用程序提供值得的安全性。

原文始发于微信公众号（菜鸟小新）：适用于 Kubernetes 1.6 的 CIS 基准测试