本文为译文，原文地址：https://www.cncf.io/blog/2022/09/09/securing-kubernetes-cluster-using-kubescape-and-kube-bench/。
随着企业采用云原生技术，Kubernetes 已成为容器编排的主要选择工具。部署和管理应用程序从未如此简单。然而，保护集群就像使用容器的未知水域一样。攻击者发现并利用新的方法来侵入系统，而社区则全天候工作以保护它。
为了提高集群的安全性，需要了解它是什么以及它是如何工作的。为此，需要对集群进行详细分析，包括存储 Kubernetes 组件配置的文件系统，逐行分析工件等。NSA、MITRE、CIS 等机构发布基准并不断升级维护 Kubernetes 集群的安全性。然而，这些基准测试涵盖了如此多的细节，以至于手动检查成为一个非常漫长的过程。
在探索如何为 Kubernetes 集群设置漏洞评估扫描时，我们遇到了两个工具：kube-bench 和 Kubescape。
在这篇博文中，我们将讨论这些工具的开源产品、它们的功能、它们如何工作、它们使用哪些框架、何时使用它们以及为什么使用它们，以及它们如何相互补充。那么，让我们开始吧。
什么是 kube-bench？
kube-bench 是来自 Aqua Security的工具。它是一个开源产品，可根据 Internet 安全中心指南分析集群。
kube-bench 是如何工作的？
kube-bench 是一个不会在集群上连续运行的工具。相反，可以使用简单的命令在所有节点上运行它。测试分为不同的部分，例如：
主节点安全配置
etcd 节点配置
控制平面配置
工作节点安全配置
Kubernetes 政策
每个部分都会发布自己的测试、对失败或警告的测试的补救措施，以及它的摘要（PASS/FAIL/WARN/INFO 检查的计数）。最后，将发布总体摘要。以下是 minikube 集群上的 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 the
master node.
For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
1.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.yaml
1.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.yaml
1.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.yaml
1.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.yaml
on the master node and set the below parameter.
--anonymous-auth=false
1.2.5 Follow the Kubernetes documentation and setup the TLS connection between
the 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=<ca-string>
摘要示例
24 checks PASS
27 checks FAIL
13 checks WARN
0 checks INFO
部署方法
kube-bench 可以作为主机上的简单命令执行，也可以使用 Docker 命令作为主机上的容器执行，或者作为 Kubernetes 集群中的作业执行。如果它在容器/pod 中运行，则需要访问主机系统的 PID 命名空间。在 AKS、EKS、GKE、On-prem 集群、Openshift 和 ACK（Alibaba Cloud Container Service For Kubernetes）中运行 kube-bench 的方法不同，但有 据可查。
何时使用 kube-bench？
Kube-bench的分析在扫描节点(主节点、工作节点、etcd节点)时非常出色。它给出了关于配置文件的所有权和权限以及错误配置的标志和参数的非常精确的说明。它还在适用的地方直接给出命令。然而，我们的经验是，当涉及到扫描集群内的工件时，输出更多的是指导方针。没有关于哪个工件有错误配置的特定信息。以下是Kubernetes策略部分中的一些检查和纠正示例:
检查
[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)
纠正示例
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.
5.2.1 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.privileged field is omitted or set to false.
5.2.2 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostPID field is omitted or set to false.
5.2.3 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostIPC field is omitted or set to false.
5.2.4 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostNetwork field is omitted or set to false.
5.2.5 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.allowPrivilegeEscalation field is omitted or set to false.
这样的输出并没有给出关于集群的清晰画面。 例如，上述输出未提供有关违反安全控制的特定字段/集群角色绑定的任何信息。 如果您的集群很大，那么这种信息并没有多大帮助。
与其他工具的集成
在撰写本文时，kube-bench 不提供与其他工具的任何原生集成。 但是，AWS Security Hub 已将其添加为开源工具集成。 以下是有关 kube-bench 与其他工具集成的更多详细信息。 除此之外，kube-bench 还提供 JSON 格式的扫描输出，因此如果您想根据集群扫描结果制作报告或创建警报，您可以围绕它创建一个脚本。
所以，这都是关于 kube-bench 的。 正如我们在上面看到的，当我们想要从节点端保护集群时，这很棒。 但是，在检查 Kubernetes 工件配置中的漏洞时，它没有提供精确的信息。 使用我们即将讨论并且最近变得流行的另一个工具（称为 Kubescape）可以很好地涵盖这些内容。
什么是 Kubescape？
Kubescape 是来自 ARMO Security 的工具。 它的开源产品根据 NSA 和 MITRE 指南分析集群。 除了这两个之外，Armo 自己还为 Kubernetes 开发了两个安全框架，名为 ArmoBest 和 DevOpsBest，它们与 Kubescape 一起使用。
Kubescape 是如何工作的？
Kubescape 具有在集群内部以及 CI/CD 管道中运行的能力。这种灵活性使您可以持续检查您的集群以及 CI/CD 管道。
与 kube-bench 不同的是，Kubescape 的测试没有分段。相反，Kubescape 使用控件。在 Kubescape 的生态系统中，NSA/MITRE/ArmoBest/DevOpsBest 指南被分解成小的策略集（称为控制）。每个控件都有自己的一组规则，根据这些规则扫描集群或管道。使用 Web 界面，您还可以通过组合门户上提供的控件来创建自己的框架以与 Kubescape 一起使用。扫描配置后，它将详细信息发送到 ARMO 的门户。您还可以从 Web 界面本身查看集群/管道的安全状况。 kube-bench 和 Kubescape 之间的一个主要区别在于，在检查 Kubernetes 工件时，Kubescape 进入了特定的细节。在门户网站上，Kubescape 将您准确导航到特定工件/s 配置中由于控制失败而导致的行（示例已在下图中共享）：
如果您不想使用 ARMO 的门户，您可以简单地扫描您的集群/管道。 问题是您无法从 Kubescape 本地安排扫描。 但是，您可以为此使用诸如 cron 之类的实用程序。 以下是 CLI 输出的一些示例：
控件检查示例
[control: Naked PODs - https://hub.armo.cloud/docs/c-0073] failed 😥
Description: It is not recommended to create PODs without parental Deployment, ReplicaSet, StatefulSet etc.Manual creation if PODs may lead to a configuration drift and other untracked changes in the system. Such PODs won't be automatically rescheduled by Kubernetes in case of a crash or infrastructure failure. This control identifies every POD that does not have a corresponding parental object.
Failed:
Namespace default
Pod - bus
Namespace kube-system
Pod - storage-provisioner
Summary - Passed:22 Excluded:0 Failed:2 Total:24
Remediation: Create necessary Deployment object for every POD making any POD a first class citizen in your IaC architecture.
[control: Enforce Kubelet client TLS authentication - https://hub.armo.cloud/docs/c-0070] passed 👍
Description: Kubelets are the node level orchestrator in Kubernetes control plane. They are publishing service port 10250 where they accept commands from API server. Operator must make sure that only API server is allowed to submit commands to Kubelet. This is done through client certificate verification, must configure Kubelet with client CA file to use for this purpose.
Summary - Passed:2 Excluded:0 Failed:0 Total:2
摘要示例
FRAMEWORKS: DevOpsBest (risk: 43.94), MITRE (risk: 15.93), ArmoBest (risk: 27.62), NSA (risk: 30.72)
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| CONTROL NAME | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK-SCORE |
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| Access Kubernetes dashboard | 0 | 0 | 98 | 0% |
| Access container service account | 41 | 0 | 45 | 91% |
| Access tiller endpoint | 0 | 0 | 0 | skipped |
| Allow privilege escalation | 24 | 0 | 25 | 96% |
| Allowed hostPath | 4 | 0 | 25 | 16% |
.
.
.
.
.
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| RESOURCE SUMMARY | 131 | 0 | 185 | 28.35% |
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
部署方法
Kubescape 可以部署在任何 Kubernetes 集群上进行例行检查，也可以部署在 CI/CD 管道中，以确保不会出现错误配置进入生产环境。 它可以在任何机器上运行，前提是机器上应该存在用于访问集群的 kubeconfig 文件。
可以使用 ARMO 门户上提供的一组简单命令来安装或运行它。 在 ARMO 的门户上注册后，您将获得一个帐户 ID。 您还将获得一组包含此帐户 ID 的命令，以便您的所有集群或 CI/CD 扫描可以显示在一个页面上。 下图显示了这些命令的外观：
如果您想在物理隔离 Kubernetes 集群中运行 Kubescape，那么您可以从 Kubescape 的 Github 存储库安装 Kubescape 实用程序，并按照 Kubescape 的 Github 存储库中的离线/物理隔离环境支持部分下的说明进行操作。
在哪使用最好?
Kubescape 可以在您的常规集群和临时集群（为 CI/CD 检查创建的集群）上高效工作。 Kubescape 在集群内的工件配置（换句话说，Kubernetes 对象）方面表现出色。 这背后的原因是 ARMO 门户网站上对每一次失败的检查都有详细的分析。 在 ARMO 的门户上，您可以将问题深入到配置中的单行，因为控制失败。
集成
Kubescape 原生提供与 Prometheus、Slack、Jenkins、CircleCI、Github、GitLab、Azure-DevOps、GCP-GKE、AWS-EKS 等的集成。ARMO 的官方文档和 ARMO 门户上的集成页面都详细记录了集成步骤。
结论
Kubescape 和 kube-bench 在它们支持的框架、部署方式以及执行扫描和提供结果的方式方面都不同。不如说两者都有自己的强项。在扫描主机、文件权限和所有权、不同 Kubernetes 控制平面组件的标志时，kube-bench 证明了它的能力。另一方面，Kubescape 在扫描集群内的对象（如 pod、命名空间、帐户等）时显示了它的价值。请记住，ARMO 的门户是托管解决方案，使用它，您将拥有通过 Kubescape 与它共享有关集群内资源的信息。但是，正如我们上面所讨论的，您也可以在仅 CLI 模式下使用 Kubescape（如 Kubescape 的 GitHub 存储库中的离线/物理隔离环境支持部分所述）。
总而言之，我相信 kube-bench 和 Kubescape 是相辅相成的。 kube-bench 应该在设置集群或在集群中添加新主机时使用，因为文件权限和所有权类型是一次性任务，并且保存集群的配置以防止未经授权的访问非常重要。一旦集群/新主机启动并运行，Kubescape 可用于定期扫描集群内的工件，因为它将问题深入到单行配置。
