6.4 Kubernetes

容器编排通常被定义为自动执行操作工作以运行容器化工作负载和服务。虽然有几种潜在的容器编排工具可供选择，但 Kubernetes 在采用和使用方面无疑是行业领导者 （https://kubernetes.io）。

Kubernetes 起源于 Google 的一个容器编排项目，并在采用和使用方面迅速增长。CNCF 2021 年的一项调查发现，96% 的受访者表示使用 Kubernetes，其中 70% 的受访者表示他们在生产中使用 Kubernetes（www.cncf.io/wp-content/ uploads/2022/02/CNCF-AR_FINAL-edits-15.2.21.pdf）。据估计，全球有 390 万 Kubernetes 开发人员，同比 （YoY） 大幅增长。在一项类似的红帽调查 （www.redhat.com/en/enterpriseopen-source-report/2022?intcmp=701f2000000tjyaAAA） 中，85% 的 IT 领导者认为 Kubernetes 对他们的云原生应用程序战略极其重要或非常重要。

如前所述，Kubernetes 的起源可以追溯到 Google 的早期内部项目，最著名的是 2003 年左右的 Borg 系统。这个项目发展成为一个名为 Omega 的项目，这是谷歌在 2013 年推出的另一个集群管理系统。最后，在 2014 年，Google 开源了 Borg，并将其作为 Kubernetes 引入。从那时起，Kubernetes 的采用和增长才得以加速，推出了额外的版本和功能以及强大的爱好者生态系统。相关的行业活动，如 KubeCon，一个面向 Kubernetes 和云原生生态系统的会议，吸引了来自行业领导者的参与者，并重点介绍了该领域的一些新兴功能和创新。

尽管 Kubernetes 发展迅速，但一些软件供应链组织仍然与 Kubernetes 及其相关技术的使用和实施有关。Kubernetes 在架构上由 Kubernetes 集群中的多个组件组成。这些组件包括 Kubernetes API 服务器。Kubernetes API 服务器验证和配置 Kubernetes 对象的数据，包括 Pod、服务、复制控制器和其他 Kubernetes 实体。

2022 年，每天积极扫描整个互联网 IPv4 空间的 Shadow Server 组织能够找到 380,000 个公开暴露的 Kubernetes API 服务器 （www.shadowserver.org/news/over-380-000-open-kubernetesapi-servers）。他们的研究指出，他们能找到的已知 Kubernetes 实例中有 84% 是公开的，并返回 HTTP 200 OK 响应。许多安全和 Kubernetes 专家指出，这并不意味着这些集群不安全或易受攻击，因为它们的存在通常是由于 CSP 托管 Kubernetes 服务的默认配置。但是，它确实显示了轻微的错误配置如何暴露集群、容器和在其上运行的代码。真正的错误配置可能允许恶意参与者破坏群集及其工作负载，并可能横向转向其他组织资产。

与 Kubernetes 供应链威胁相关的另一个促成因素是 Kubernetes 是通过清单文件实现的。这些是声明性 YAML 或 JavaScript 对象表示法 （JSON） 配置文件，用于描述 Kubernetes 集群的运行方式，定义各种 Kubernetes API 对象的所需状态。这意味着它们是用代码编写的，并且能够像其他形式的传统代码和配置文件一样保存、存储和共享。
使用各种资源管理复杂的 Kubernetes 部署可能是一项复杂的任务。通常，组织将使用 Helm 图表，这是一种用于描述一组相关 Kubernetes 资源的文件集合的打包格式。Helm 图表与 Kubernetes 资源非常相似，通常以 YAML 格式进行描述。它们被存储、共享和可用在诸如 Artifact Hub 之类的地方，Artifact Hub 是一个基于 Web 的应用程序，可用于查找、安装和发布各种 CNCF 项目（包括 Kubernetes）的包和配置。

虽然使用现存的Helm图表和配置文件可以加快实现和部署的时间，但这样做也会带来传统软件代码存在的风险，如恶意或易受攻击的代码或配置。例如， Palo Alto的研究小组Unit 42在他们的“2H 2021”白皮书中研究了Kubernetes和Helm（https://paloaltonetworks.com/prisma/unit42-cloud-threat-research-2h21.html）。研究人员使用一种名为“helm-scanner”的工具来评估Artifact Hub上的Helm图表和YAML文件，发现超过99%的图表容器有不安全的配置，近10%的容器至少有一个关键或高度不安全的配置。

研究人员还指出，与代码类似，Helm图表通常依赖于其他图表，他们在图表中识别的62%的错误配置是由于依赖图表。他们还指出，依赖项计数越高，平均错误配置计数就越高。这些错误的配置包括诸如过度特权的容器和不安全的网络配置等项。因此，尽管现代应用程序和工作负载经常被部署在 Kubernetes的容器上，但 Kubernetes的配置文件和图表经常被复制和共享固有的漏洞和错误配置本身，潜在地威胁到驻留在这些集群上的所有工作负载。

在 Kubernetes的背景中，配置和声明性显示构成了自己的风险，但恶意行为者通常是在 Kubernetes工作负载并使用容器图像的生命周期渗透 Kubernetes供应链之后。这些攻击向量可能包括基本映像、应用程序代码和依赖关系、存储库、OSS组件和其他相关资源。如果邪恶的参与者可以让恶意代码在容器化的工作负载上运行，特别是没有适当的Kubernetes安全配置，它们不仅会影响单一的工作负载，还可以影响集群中其他潜在的工作负载，或者更广泛的说，影响组织的企业系统，这取决于适当的架构和配置。在Kubernetes的背景下确保适当的供应链安全将意味着确保您有一个安全的 Kubernetes的体系结构和配置。

对于想从这方面着手的组织团体的建议当然是Kubernetes文档和最佳实践，但也要利用行业指导的形式下的来源，如 Kubernetes CIS Benchmark（www.cisecurity.org/benchmark/kubernetes）或Kubernetes Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG)。这些指导源集中于核心活动，如保护Kubernetes 体系结构的控制平面组件，包括主节点、控制器管理器、调度器等。它们还包括与正确实施安全策略和基于角色的访问控制（RBAC）、网络策略和秘密管理相关的控制和配置。未能实现这些安全实践和配置可能会影响节点和集群内的工作负载，并可能允许到它们所连接的企业环境中的其他系统的横向移动。

组织也经常使用CSP的管理Kubernetes服务，如谷歌的Kubernetes Engine（GKE）或亚马逊的Elastic Kubernetes（EKS）。使用这些管理的Kubernetes产品可以通过“rolling your own”Kubernetes来减轻一些管理开销（例如，拥有整个控制平面的活动和配置）。然而，使用托管的Kubernetes产品并不是没有它自己的问题。在CSP环境中仍然需要安全的配置，如身份和访问管理（IAM）、加密和密钥管理、网络和运行工作负载的节点的元数据服务，再加上信任和依赖云提供者的固有特性。

了解保护Kubernetes集群的最佳资源之一是Kubernetes文档页面 (https://kubernetes.io/docs/tasks/ administer-cluster/securing-a-cluster)。 CIS Kubernetes Benchmark， DISA Kubernetes STIG和NSA Kubernetes Security Guide也是优质资源，但用户还应该更广泛地确保，如果他们所使用的云平台的云本地安全最佳实践也会得到解决。

组织可以使用工具来确保Kubernetes的集群和部署，以及Kubernetes的安全最佳实践。一些例子包括来自Aqua Security（https://github.com/aquasecurity/kube-bench）的kube-bench，一个OSS工具，检查部署的Kubernetes配置是否与 CIS Kubernetes Benchmark一致。与Kubernetes本身类似，kube-bench使用了用YAML编写的测试，它可以随着基准测试的发展而进行修改。Aqua的另一个著名工具是kube-hunter，它寻找Kubernetes集群中的安全弱点。kube-hunter可以在机器或端点上运行，并使用IP进行远程扫描。此外，它可以在集群中的机器上运行，甚至可以作为集群中的pod运行。kube-hunter的一个独特方面是，它不仅支持审计/评估模式，还支持主动搜索模式，这可以改变集群的状态，利用被发现的漏洞。特别是由于后一种原因，kube-hunter文档特别指出，该工具不应该用于您不拥有的集群，其中包括使用受管理的Kubernetes产品。

想要了解与Kubernetes相关的各种攻击策略和技术的组织也可以利用资源，如微软对Kubernetes的Threat Matrix（www.microsoft.com/en-us/ security/blog/2020/04/02/attack-matrix-kubernetes），如图6.4所示。

就像MITRE ATT&CK一样，这个资源可以帮助组织了解其环境的攻击表面，以及恶意行为者所使用的各种策略。微软在他们的Threat Matrix中采取了类似的方法，但针对Kubernetes进行了定制，包括揭露Kubernetes的秘密和利用集群内部网络等活动，如图6.4所示。这些战术范围从初始访问阶段到影响，很像MITRE ATT&CK。

另一个类似的资源是 由Weaveworks传播的MITRE ATT&CK Matrix for Kubernetes（www .weave.works/blog/mitre-attack-matrix-for-kubernetes），它使用类似于微软的Threat Matrix，还包括一个收集阶段，它专注于对手用于收集信息的技术，特别是从私人注册中心收集图像。尽管Weaveworks和微软的Threat Matrix之间存在差异和相似之处，但这两种资源都可以帮助组织理解以Kubernetes为中心的攻击的各个阶段，以及恶意行为者可能用来利用Kubernetes环境和协调的工作负载的相关策略。除了前面讨论过的资源，如 CIS Benchmarks，DoD STIGs，和Kubernetes Threat Matrices，组织还应该寻求采用新兴的框架，如Supply Chain Levels for Software Artifacts (SLSA)，我们会在下一章中讨论。

Kubernetes还支持各种多租赁模型，这些模型使用其集群和名称空间的构造，以促进云本地工作负载的效率、成本节约和可伸缩性（www.weave.works/blog/mitre-attack-matrix-forkubernetes）。对于部署工作负载到Kubernetes的组织来说，理解他们正在使用的租赁模型和潜在的安全和合规考虑事项是很重要的，特别是如果发生了安全事件或数据泄露，如果安全卫生和爆炸半径控制不良，可能会对租户产生级联影响。为了详细了解云原生环境中多租户的风险，云安全领导者Wiz发布了他们所谓的“PEACH Framework”，这是一个助记符，包括特权、加密、身份验证、连接硬化以及卫生等因素。该框架可以应用于Kubernetes的部署以及更广泛的多租户云环境（www.datocms-assets.com/75231/1671033753-peach_whitepaper_ver1-1.pdf）。

在Kubernetes生态系统中也支持SBOM。最值得注意的是，这包括OSS Kubernetes的bom实用程序，它利用为Kubernetes编写的代码为他们的项目生成SBOMs（https://github.com/kubernetes-sigs/bom）。Kubernetes bom工具支持从文件、图像和Docker图像中创建SBOMs，并将一组文件打包到单个文件中。您还可以从注册表中提取图像，并使用bom工具分析它们。它以 Software Package Data Exchange (SPDX) SBOM格式生成这些工件，并可以导出到一个in-toto的来源证明。In-toto是一个”超越最后一英里“或最终工件焦点的框架，旨在确保软件产品从启动到最终用户安装的完整性，使其透明地执行了什么步骤、由谁以及以什么顺序执行（https://in-toto.io/in-toto）。这些in-toto的来源证明都允许生成关于一个软件是如何生产的任何方面的可验证声明。可以利用Kubernetes的bom工具使用一个简单的”bom generate“命令创建SPDX清单。