Hello folks，我是 Luga，今天我们来介绍另一款开源容器平台安全扫描工具 - Kube-bench。作为 Aqua Security 一款出色的开源产品，其能够基于 Internet 安全中心指南分析 Kubernetes Cluster 运行行为，并为其进行安全评估。‍‍‍‍

随着企业云原生技术及生态理念的普及，Kubernetes 事实上已成为容器编排的首选工具，无论怎么说都不为过，基于其，使得部署和管理应用程序变得从未如此简单。虽然新技术的引入带来种种益处，然而，Kubernetes Cluster 的安全性便一直是云原生生态不可逾越的鸿沟。攻击者可能会想法设法地寻找各种潜在漏洞并利用新的方法闯入系统，对整个系统进行破坏性“建设”。

为了提高 Kubernetes Cluster 的安全性，在实际的业务场景中，我们往往需要了解 W & H（即“它是什么”以及“它是如何工作的”）。为此，需要对 Kubernetes Cluster 进行全方位详细分析，包括存储 Kubernetes 组件配置的文件系统，集成插件、运行环境以及其他关联要素等。NSA、MITRE、CIS 等机构发布基准并不断升级维护 Kubernetes 集群的安全。然而，这些基准测试涵盖了太多细节，使得手动检查变得非常繁琐。

【资料图】

在探索如何为 Kubernetes Cluster 进行漏洞安全评估扫描时，目前，市场上有两个比较流行的工具值得为大家推荐：Kube-bench 和 Kubescape。

在之前的博文中，我们已讨论过 Kubescape 开源产品，并对其进行深入描述：它们的功能是什么、它们如何工作、它们使用哪些框架、何时使用它们以及为什么使用它们，以及它们如何相互补充。

Kube-bench 概述

作为一个基于开源 Go 开发的应用程序，Kube-bench 主要用于检查 Kubernetes Cluster 是否根据安全最佳实践进行部署规划。它实现了 CIS Kubernetes 基准，这些基准是由互联网安全中心开发的用于以安全方式运行 Kubernetes 的指导性文档。Kube-bench 可以针对自我管理的 Kubernetes Cluster 以及由流行的云提供商（如 AWS、Azure、GKE Cluster 等）管理的 Kubernetes Cluster 执行。

除此之外，Kube-bench 还提供了 JSON 格式的扫描输出，因此如果大家想根据集群扫描结果制作报告或创建警报，可以基于此进行脚本创建并自定义配置相关策略。

工作原理

通常，Kube-bench 是一个往往不会在 Kubernetes Cluster 上持续运行的工具。相反，我们可以使用简单的命令在所有 Node 上运行，然后，基于不同的部分进行检测，从而输出修复报告及建议。具体如下所示：

1、Master Node 安全配置

2、etcd Node 配置

3、控制平面配置

4、Work Node 安全配置

5、Kubernetes 政策

基于不同的环境，执行自己的检测行为、然后，对失败或警告检测的补救措施及其摘要（通过/失败/警告/信息检查的计数）进行输出。最后，发布了一个总体的概括。

其实，无论是基于源码角度，还是其执行实施检测角度，Kube-bench 工作原理较为简单。基本上围绕“执行引擎”——>“探测扫描”——>"建议输出"等流程进行。‍‍‍‍‍‍

如下为基于不同环境的检测示例：‍‍

[INFO] 1 Master Node Security Configuration[INFO] 1.1 Master Node Configuration Files[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)[FAIL] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)[FAIL] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated)[FAIL] 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root (Automated)[FAIL] 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated)

[INFO] 1.2 API Server[WARN] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Manual)[PASS] 1.2.2 Ensure that the --token-auth-file parameter is not set (Automated)[PASS] 1.2.3 Ensure that the --kubelet-https argument is set to true (Automated)[PASS] 1.2.4 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (Automated)[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)

以及对应的修复示例：

1.1.1 Run the below command (based on the file location on your system) on themaster node.For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml1.1.2 Run the below command (based on the file location on your system) on the master node.For example,chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml1.1.3 Run the below command (based on the file location on your system) on the master node.For example,chmod 644 /etc/kubernetes/manifests/kube-controller-manager.yaml1.1.4 Run the below command (based on the file location on your system) on the master node.For example,chown root:root /etc/kubernetes/manifests/kube-controller-manager.yaml1.1.5 Run the below command (based on the file location on your system) on the master node.For example,chmod 644 /etc/kubernetes/manifests/kube-scheduler.yaml

1.2.1 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yamlon the master node and set the below parameter.--anonymous-auth=false1.2.5 Follow the Kubernetes documentation and setup the TLS connection betweenthe apiserver and kubelets. Then, edit the API server pod specification file/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.--kubelet-certificate-authority=

以及总体的概要总结输出，如下所示：

44 checks PASS37 checks FAIL19 checks WARN0 checks INFO

When Kube-bench ？

Kube-bench 提供了一个简单的工具来检查 Kubernetes 的配置（包括 Master 和 Work）是否符合最佳的安全实践（基于 CIS Kubernetes Benchmark）。

Kube-bench 在扫描节点（Master Node、Work Node、etcd Node）时的分析行为表现的非常棒。Kube-bench 能够给出关于配置文件的所有权限以及错误配置的标志和参数的非常精确的说明，以及在适用的地方直接发出命令。然而，我们发现在扫描集群内的组件时，往往输出更多的是指导方针，没有关于哪个工件配置错误的具体信息。以下是 Kubernetes 策略部分下的一些检查和修复示例：

1、Check - 检测

[INFO] 5 Kubernetes Policies[INFO] 5.1 RBAC and Service Accounts[WARN] 5.1.1 Ensure that the cluster-admin role is only used where required (Manual)[WARN] 5.1.2 Minimize access to secrets (Manual)[WARN] 5.1.3 Minimize wildcard use in Roles and ClusterRoles (Manual)

[INFO] 5.2 Pod Security Policies[WARN] 5.2.1 Minimize the admission of privileged containers (Automated)[WARN] 5.2.2 Minimize the admission of containers wishing to share the host process ID namespace (Automated)[WARN] 5.2.3 Minimize the admission of containers wishing to share the host IPC namespace (Automated)[WARN] 5.2.4 Minimize the admission of containers wishing to share the host network namespace (Automated)[WARN] 5.2.5 Minimize the admission of containers with allowPrivilegeEscalation (Automated)

2、Remediations - 修复

5.1.1 Identify all clusterrolebindings to the cluster-admin role. Check if they are used and if they need this role or if they could use a role with fewer privileges.Where possible, first bind users to a lower privileged role and then remove the clusterrolebinding to the cluster-admin role :kubectl delete clusterrolebinding [name]5.1.2 Where possible, remove get, list and watch access to secret objects in the cluster.5.1.3 Where possible replace any use of wildcards in clusterroles and roles with specific objects or actions.

部署方式

通常来说，Kube-bench 部署方式较为简单，目前一些 Kubernetes Cluster 的管理平台，例如， Rancher、Kubeoperator 等已经支持并集成 Kube-bench 工具，因此，如果已经在使用这些平台的话我们也可以直接使用平台上的相应功能来完成扫描。

针对 Kube-bench 的部署运行，如果直接从命令行运行 Kube-bench，那么，可能需要成为 root / sudo 才能访问所有配置文件。

默认情况下，Kube-bench 会尝试自动检测 Kubernetes Cluster 的运行版本，并将其映射到相应的 CIS Benchmark 版本。例如，Kubernetes 1.15 版本映射到 CIS Benchmark 版本 cis-1.15，这是对应 Kubernetes 1.15 有效的基准版本。

除此之外，Kube-bench 还尝试识别 Node 上运行的组件，并使用它来确定要运行哪些测试（例如，如果节点正在运行 API Server，则只运行 Master Node 测试）。

需要注意的是 ，使用 Kube-bench 无法检查托管 Kubernetes Cluster 的 Master Node，例如 GKE、EKS、AKS 和 ACK，因为无法访问这些节点，尽管仍然可以使用 Kube-bench 检查 Worker 这些环境中的 Node 配置。

基于 Container 部署

基于容器部署模式，主要是使用主机 PID 命名空间在容器内运行，并将配置和其他文件所在的目录挂载在主机上，以便 Kube-bench 可以检查它们的存在和权限 /etc 或 /var 等等。

具体部署方式可参考如下所示：

[leonli@192 ~ ] % docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t docker.io/aquasec/kube-bench:latest --version 1.18

需要注意的是：测试需要路径中的 kubelet 或 kubectl 二进制文件才能自动检测 Kubernetes 版本。

可以通过 -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl 来解决这个问题。除此，还需要传入 kubeconfig 凭据。具体如下所示：

[leonli@192 ~ ] % docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t docker.io/aquasec/kube-bench:latest 

当然，除了上述的启动方式外，还可以通过将它们安装在默认配置上来使用自己的配置 /opt/kube-bench/cfg/ 进行，具体如下所示：

[leonli@192 ~ ] % docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t -v path/to/my-config.yaml:/opt/kube-bench/cfg/config.yaml -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config docker.io/aquasec/kube-bench:latest

基于 Kubernetes 部署

除了上述的部署模型外，另一个经典的部署方式便是可以在 Kubernetes Cluster 的 Pod 内运行 Kube-bench，但此种模型需要访问主机的 PID 命名空间以检查正在运行的进程，以及访问主机上存储配置文件和其他文件的某些目录等。

需要注意的是，要在 Master Node 上运行测试，需要在该 Node 上安排 Pod。这涉及在 Pod 规范中设置 nodeSelector 和 tolerations （容忍度）。

自 Kubernetes v1.11 以来，应用于 Master Node 的默认标签发生了变化，因此如果使用的是旧版本，则可能需要修改 nodeSelector 和 tolerations 才能在 Master Node 上运行作业。

源码部署

此种部署方式通常较为简单，首先在设备上安装并配置好 Go 环境变量，然后运行下列命令即可，具体如下所示：‍‍‍‍

[leonli@192 ~ ] % go get github.com/aquasecurity/kube-bench[leonli@192 ~ ] % cd $GOPATH/src/github.com/aquasecurity/kube-bench[leonli@192 ~ ] % go build -o kube-bench .[leonli@192 ~ ] % ./kube-bench --help# Run all checks[leonli@192 ~ ] % ./kube-bench

公有云平台部署

针对第三方公有云平台，主要涉及 AKS Cluster、EKS Cluster、On-prem Cluster、OpenShift、 GKE Cluster 以及 ACK（Alibaba Cloud Container Service For Kubernetes） Cluster 等等。因各大厂商平台接口标准的差异性，使得在这些集群中运行存在各种限制及要求，导致运行 Kube-bench 的方法不尽相同。

基于上述所述，相对于 Kubescape，Kube-bench 在扫描主机、文件权限和所有权、不同 Kubernetes 控制平面组件的标志时展现了它的优秀才能；而 Kubescape 则在扫描集群内的对象（例如 Pod、名称空间、帐户等）时显示了它的价值。无论基于那种工具，能够解决实际的安全问题才是根本。‍

因此处内容涉及面较小，基本上体现在原理及执行层面，故大家可以参考本文进行相关实践。本文解析到此为止，希望对大家有用。关于 Kube-bench 更多需要了解的信息，欢迎大家交流、关注！

Adiós !