CIS Kubernetes 基线测试

CIS 基线

CIS Benchmarks 很多人对它并不陌生，可以说业内人士对于“最佳实践”是情有独钟的。甚至有人在开会时，会常常把“Best Practice”挂在嘴边。我们今天就来聊聊 CIS Benchmark for Kubernetes。

当下 CIS 基线已经被广泛接受为保障 Kubernetes 集群安全的事实标准。有了基线文档，我们该怎么利用它呢？该怎么规划基线测试呢？

开始之前先介绍一下 CIS®(Center for Internet Security)，它是一个非盈利组织，CIS Benchmarks 提供了一系列指导手册来保护容易受到网络攻击的操作系统、软件和网络。Kubernetes (K8S) 基线手册只是这一系列文档中的一小部分，归类到“容器和虚拟机”这一个类别下面。

总体上说 CIS Benchmarks 就是安全配置系统的配置基线和最佳做法。目的是为包括系统安装、应用部署、数据库部署等在内的具体的技术实施提供最佳实践。

CIS K8S 基线

CIS K8S 基线已经被广泛接受为保障 Kubernetes 集群安全的事实标准。它提供了行业认可的指标，该指标可以用来衡量 Kubernetes 集群的安全状况。它将信息安全社区领域的知识与 Kubernetes 中的 API、交互和总体控制路径的深刻理解相结合。

那么 CIS Kubernetes 基线就是指导大家如何保护 Kubernetes 服务器软件的一系列最佳做法。CIS Kubernetes 基线是针对开源 Kubernetes 发行版编写的，所以不同的版本有不同的基线文档。

当工程师试图了解他们保护集群所需的所有位置时，他们可以从基线中了解到数十种攻击的可能性以及如何缓解它们。

容器云服务基线

现在大的云服务提供商很多都有被 CIS 基金会基线涵盖:

1. 亚马逊网络服务

2. 微软 Azure

3. 谷歌云计算平台

4. 甲骨文云基础设施

5. IBM 云

6. 阿里巴巴云

对于容器云服务，因为不同的服务商在实现细节上略有不同，他们的基线测试存在一些测试用例的差异，和计算最后分数的差异。本人看到的基线文档有这几个：

• CIS Amazon EKS 基线

• CIS 微软 AKS 基线

• CIS 谷歌 GKE 基线

• CIS Alibaba ACK 基线

以 CIS GKE 基线为例说明一下，它算是 CIS Kubernetes 基线的子基线，专门应用于 GKE 发行版。该基线来自现有的 CIS 基线，但移除了不可由用户配置或管理的项，同时添加了 Google Cloud 特有的其他控制措施。

容器云服务安全责任共担

使用服务商提供的容器云服务和由 K8S 自己搭建的私有容器云还是有很大不同的。对于容器云服务这种托管式服务，客户是不能完全控制整套环境的。

我们就以谷歌的 GKE 基线来举例，在 GKE 中， 谷歌负责管理以下 Kubernetes 组件：

• 控制层面（主服务器），包括控制层面虚拟机、API 服务器、虚拟机上的其他组件以及 etcd

• Kubernetes 发行版

• 节点的操作系统

所以对于 GKE 等托管式服务，并非基线上的所有内容都由客户负责，而且客户也无法直接审核或修正某些建议。所以这些由谷歌负责的组件的安全问题会完全由谷歌负责，除此之外的组件的安全问题就归类到了“安全责任共担”的部分了。你没有理解错，有一部分是客户自己需要负担起安全责任的。这个后面可以单独讲一讲。

所以 GKE 用户真正需要关心的基线主要就是:

• Worker Nodes（第 4 部分）来自 CIS Kubernetes 基准。

• Policies （第 5 部分）也来自 CIS Kubernetes 基准。

• Managed services (第 6 部分) 是特定于 GKE 的新内容。

对容器云做基线检测举例

有了基线文档，我们怎么利用它呢？来上个图：

手动评估的话，这会是一个十分耗时且容易失败的任务。这就是 kube-bench 大展身手之处。kube-bench 是一款针对 Kubernetes 的安全开源检测工具，用于根据 CIS Benchmark 自动评估集群。再挖个坑，后面会尝试在国内的公有容器云上跑一下这个这个检测工具，后续再分享给大家。

本文先拿谷歌 GKE 基线文档来举个栗子，栗子看起来有点轻，能说明问题就好。

GKE 文档 4.2.1 这一条目是检查 Kubelet anonymous-auth 参数设置。默认情况下找个值是 true，允许表示 kubelet 服务器可以接受匿名请求。最佳实践文档则建议用户将其设置为 false。在检测时，如果这个测试通过了，就是得分项。

4.2 Kubelet 4.2.1 确保将 --anonymous-auth 参数设置为 false 计分 L1 通过

而 GKE 文档 5.2.1 这一条目是建议尽可能减少特权容器，这个在该文档中就是个不计分的用例。

5.2 Pod 安全政策 5.2.1 尽可能减少特权容器的准许 不计分 L1 取决于环境

在基线文档里，还有如何应对基线测试发现的问题。基线文档看起来很长，不过可以根据实际需要，有选择的去看对应的部分。

【大鱼安全团队出品】- 大鱼安全：国内首个 SaaS 版云原生安全平台 https://www.greatersecurity.com.cn/