云安全攻防 - 浅谈k8s

云计算发展历程的时间轴如下图所示，从物理机过渡到传统的IaaS阶段，进而发展为早期的PaaS，直至发展到如今的基于Kubernetes架构的新兴PaaS平台。

传统：一切自行解决。购买硬件，自行安装操作系统等

IAAS：阿里云、腾讯云等云安全厂商。提供基础硬件，允许自定义安装操作系统

CAAS：Docker技术。提供基础操作系统，允许自定义运行环境

PAAS：Mysql、MangoDb、Node.js。提供软件部署平台，关注业务开发

FAAS：阿里云函数计算、腾讯云Serverless、Azure serverless。解决分布式问题，更专注服务端业务逻辑场景

SAAS：常用的SaaS产品类型有财税法务、人力资源、通用办公、IT运维、市场营销、数据分析、销售商务、客服、项目管理、ERP、设计等。厂商统一部署，提供软件服务。

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，促进声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 服务、支持和工具广泛可用。Kubernetes 这个名字源自希腊语，意思是舵手或飞行员。K8s 作为缩写，是通过计算“K”和“s”之间的八个字母而得出的。

个人认为，K8S既不是PAAS，也不是IAAS。它是一个容器编排引擎，这使得它更像一个CaaS，然而Kubernetes需要IAAS提供虚拟机资源，本身又可以作为PAAS来使用。

Kubernets整体架构的核心组件，如下所示：

整个系统由Master与Worker Node组成。

Master组件如下：

1. kube-apiserver

2. etcd

3. kube-scheduler

4. kube-controller-manager

Worker Node组件如下：

1. kubelet

2. kube-proxy

3. Container runtime

Kubernetes的各组件与API Server通信时，采用List-Watch机制，通过API server获取etcd配置与状态信息，进而触发行为。

补充说明：Kubernetes抽象出一个Pod对象，是一组（一个或多个）容器， 这些容器共享存储、网络等， 这些容器是相对紧密的耦合在一起的。Pod是Kubernetes内创建和管理的最小可调度单元，调度过程是按Pod整体所需资源一起进行调度的。但Pod本身只是逻辑上的概念，在容器管理这层并不认识Pod对象。Pod是整个编排过程中操作的核心，很多对象直接或间接的同Pod相关联，如下图所示。

下面通过流程图和拓扑图来进一步了解Kubernets整体运作机制。

首先，下图是kubectl创建一个Pod时，各个组件与API Server的交互流程。

接下来，Kube-proxy与API Server通信来获取有关服务 (ClusterIP) 以及相应 pod IP 和端口（端点）的详细信息，然后使用IPTables/IPVS的模式来创建/更新规则，以将流量路由到服务后面的 Pod。

上述是K8s核心组件的简单介绍。除了核心组件，还有一些附加组件（开放插件）。为了便于系统的扩展，Kubernetes中开放了以下接口可对系统资源（计算、网络、存储）插件进行扩展，可分别对接不同的后端来实现自己的业务逻辑。

1. CRI（Container Runtime Interface）：容器运行时接口，提供计算资源。

2. CNI（Container Network Interface）：容器网络接口，提供网络资源。

3. CSI（Container Storage Interface）：容器存储接口，提供存储资源。

4. CoreDNS：DNS 服务器，CoreDNS 充当 Kubernetes 集群内的 DNS 服务器。

5. Metrics Server：用于资源指标，可帮助您收集集群中节点和 Pod 的性能数据和资源使用情况。

6. Web UI：Kubernetes 仪表板，使 Kubernetes 仪表板能够通过 Web UI 管理对象。

了解容器化环境的攻击面是为这些环境构建安全解决方案的第一步。下面介绍的矩阵可以帮助我们识别针对K8S的不同威胁的防御能力方面差距，补全安全威胁短板和瓶颈，提高集群的安全性。

初始访问是指攻击者可能用来访问 Kubernetes 集群的策略。他们可以通过破坏集群上部署的各种资源或直接破坏 Kubernetes 控制平面中处理集群管理的组件来实现此目的。

1-使用云凭证

如果 Kubernetes 集群部署在公共云中，并且云凭证遭到泄露，攻击者可能会访问集群的管理层。凭证泄露可能会导致整个集群的泄露，也可能导致集群被接管。

2-仓库中的恶意镜像

集群中运行的受损、不受信任或不安全的镜像可能会导致其受损。它可以从公共镜像仓库（例如，Docker Hub）下载，从不受信任的基础镜像构建，或者由攻击者添加到私有仓库并由用户拉取。它可能包含允许攻击者访问集群的恶意代码。

3-Kubeconfig配置

kubectl 使用的 kubeconfig配置包含集群的位置和凭据。如果集群作为云服务托管，受感染的客户端可能会发出云命令来下载此文件。如果攻击者可以访问此文件，他们就可以使用它来访问集群。

4-应用程序漏洞

具有漏洞的容器化、面向公众的应用程序使组织容易受到威胁行为者的攻击。如果它们在集群中运行，攻击者可能会获得对集群的初始访问权限。他们还可能利用该漏洞访问其他应用程序、访问敏感数据或发起拒绝服务 (DoS) 攻击。

5-暴露的敏感接口

当敏感接口暴露于互联网时，就会产生安全风险。默认情况下不需要身份验证的框架特别容易受到攻击。暴露此类框架允许恶意行为者获得对敏感接口的未经身份验证的访问并在集群中运行代码或部署容器。此前已被利用的接口之一是 Kubernetes 仪表板。

第二种策略描述了攻击者在 Kubernetes 集群内运行恶意代码以实现某些目标的各种技术。要运行此代码，他们可能会启动一个新的 Pod、获得对正在运行的 Pod 的访问权限或利用应用程序漏洞。

1-容器执行

攻击者可以使用 exec 命令 kubectl exec 在集群容器中远程运行恶意命令。如果他们有权限，他们可能会使用合法镜像（例如作为后门容器的操作系统镜像）来执行恶意代码并危及集群内的资源。

2-容器内的Bash/CMD

在这种技术中，具有权限的攻击者可以在容器内运行 bash 脚本来执行恶意代码并危及集群资源。

3-新容器

具有权限的攻击者可以通过部署容器来使用 Kubernetes 集群中的恶意代码。他们可能会在集群中部署新的 Pod 或控制器，例如 Deployments、DaemonSet 或 ReplicaSet。然后，他们可以创建新资源来执行恶意代码并危及集群资源。

4-应用程序漏洞利用 (RCE)

某些集群中的应用程序可能包含允许远程执行代码的漏洞。攻击者可能利用该漏洞在集群中执行恶意代码。他们还可能危害集群中的其他资源、访问元数据服务器上的敏感数据或引起 DoS 攻击。如果服务帐户已安装到容器，它们可以使用其凭据将请求发送到 kubelet 只读 API 服务器。

5-在容器内运行的SSH服务

在容器内运行的 SSH（安全套接字外壳）服务容易受到威胁行为者的攻击。如果攻击者通过暴力破解或网络钓鱼获得该容器的凭据，他们可能会远程访问该容器以运行恶意代码并危及资源。

6-sidecar注入（旁路注入）

Sidecar容器是一个附加容器，位于主容器旁边，并与 Kubernetes Pod 中的其他容器共享存储和网络资源。攻击者可能会将 sidecar 容器注入集群中的合法 Kubernetes Pod 中，以运行其恶意代码并隐藏其活动。

攻击者使用持久化技术来保留对 Kubernetes 集群的访问并维持在其中的存在，即使他们失去了最初的立足点。为此，他们可以利用 Kubernetes 控制器、将文件装载到容器或运行重复的 Kubernetes 作业。

1-后门容器

攻击者可以利用 DaemonSets 或 Deployments 等 Kubernetes 控制器来确保集群的一个或所有节点中始终运行恒定数量的容器。他们可能在集群容器中执行恶意代码。

2-可写主机路径挂载

hostPath 卷将文件或目录从主机挂载到容器。如果攻击者有权在集群中创建新容器，他们可能会使用可写的 hostPath 卷来执行此操作。这允许它们保留在底层容器主机上，例如，通过在主机上创建 cron 作业。

3-Kubernetes CronJob

Kubernetes 作业控制器创建一个或多个 Pod 来完成特定任务。它还确保指定数量的 Pod 成功终止。它可用于运行为批处理作业执行有限任务的容器。Kubernetes CronJob 按定期计划创建作业。攻击者可以利用 CronJob 来安排恶意代码的执行，这些代码将作为集群中的容器运行。

4-恶意准入控制器

威胁行为者可能会使用 Kubernetes 中的恶意准入控制器来访问凭证。其中一个控制器是 ValidatingAdmissionWebhook，它是一种通用的内置控制器，其行为由部署在集群中的准入 Webhook 决定。攻击者可能会使用此 Webhook 拦截敏感信息（例如对 API 服务器的请求）并记录机密。

此策略包括使攻击者能够在环境中获得额外或更高权限的技术。他们可以使用这些权限来访问集群中的更多资源或在集群内执行其他操作。在容器化环境中，他们可以从容器访问节点。

1-特权容器

特权容器具有主机的所有功能，并且没有常规容器的限制。如果攻击者获得对特权容器的访问权限或有权启动新的特权容器，他们就可以获得对主机资源的访问权限，或危及同一主机上运行的其他容器。

2-集群管理绑定

Cluster-admin 是 Kubernetes 中内置的高权限角色。具有此角色的用户拥有对集群的完全访问权限，并且可能会危害集群。具有在集群中创建绑定和集群绑定的 RBAC（基于角色的访问控制）权限的攻击者可以创建与 cluster-admin 角色或其他具有高权限的角色的绑定。

3-主机路径挂载

hostPath 卷将文件或目录从主机挂载到容器。这可能允许攻击者获得对底层主机或资源的访问权限、从容器到主机的破坏，或者危及同一主机上运行的其他容器。

4-访问云资源

攻击者可以使用此技术来访问 Kubernetes 云集群中的单个容器，从而访问集群外部的其他云资源。例如，如果他们获得对 Azure Kubernetes 服务 (AKS) 中的服务principal凭据文件的访问权限，他们可能能够使用这些凭据来访问或修改云资源。

此策略是指攻击者用来避免检测和隐藏其活动的技术。

1-清除容器日志

攻击者可能会删除受感染容器上的应用程序或操作系统日志，以试图阻止检测到其活动。

2-删除 Kubernetes 事件

Kubernetes 事件是一个 Kubernetes 对象，用于记录集群中资源的状态更改和故障。示例事件包括节点上的容器创建、映像拉取或 Pod 调度。

Kubernetes 事件对于识别集群中发生的更改非常有用。因此，攻击者可能想要删除这些事件（例如，通过使用：“kubectl delete events-all”），试图避免检测到他们在集群中的活动。

3-Pod/容器名称相似度

由 Deployment 或 DaemonSet 等控制器创建的 Pod 名称中带有随机后缀。攻击者可以利用这一事实并命名他们的后门 Pod，因为它们是由现有控制器创建的。例如，攻击者可以创建一个名为coredns-{random suffix}的恶意 Pod ，它看起来与 CoreDNS 部署相关。

此外，攻击者还可以将其容器部署在管理容器所在的 kube-system 命名空间中。

4-从代理服务器连接

攻击者可能会使用代理服务器来隐藏其原始 IP。具体来说，攻击者经常使用 TOR 等匿名网络进行活动。这可用于与应用程序本身或 API 服务器进行通信。

此策略是指攻击者用来窃取敏感凭证（例如应用程序机密、密码和令牌）的技术和活动。这些凭据可由用户或服务帐户使用。在容器化环境中，攻击者可能会窃取云或应用程序凭证、身份或存储在集群中的秘密。通过窃取这些凭据，他们可以访问应用程序、云资源或集群资源（例如 Pod、控制器或其他 Kubernetes 对象）。

1-列出 K8s (Kubernetes) Secret

Kubernetes Secret 是使组织能够存储和管理敏感凭证的对象，包括集群中的密码、令牌、密钥和连接字符串。默认情况下，K8S Secret 未加密地存储在 API 服务器的底层数据存储 (etcd) 中，因此任何有权访问 etcd 或 API 的人都可以检索或修改 Secret。有权从 API 服务器检索机密的攻击者可能会访问敏感信息，包括关键服务（例如数据库服务）的凭据。

2-挂载服务principal

攻击者可以使用此技术来访问集群中的单个容器。这可能允许他们访问云凭证资源。例如，在 Azure Kubernetes 服务 (AKS) 中，每个节点都包含一个存储在 /etc/kubernetes/azure.json 中的“服务principal”凭据。访问此服务principal文件的攻击者可以使用其凭据来访问或修改云资源。

3-访问容器服务帐户（SA）

在 Kubernetes 中，服务帐户 (SA) 是应用程序身份。默认情况下，Kubernetes 集群中的每个 Pod 都会挂载 SA。它允许容器向 Kubernetes API 服务器发送请求。获得 Pod 访问权限的攻击者可以获得 SA 令牌并在集群中执行未经授权的操作。如果启用 RBAC，SA 权限由与其关联的角色绑定决定。但如果未启用 RBAC，SA 令牌将授予攻击者无限权限和对集群的完全访问权限。

4-配置文件中的应用程序凭据

机密存储在 Kubernetes 配置文件中，例如作为 pod 配置中的环境变量。如果攻击者可以通过查询 API 服务器或访问开发人员端点上的文件来访问这些配置，他们将能够窃取这些机密并使用它们来访问集群资源。

5-访问托管身份凭证

“托管身份”及其秘密由云提供商管理，分配给虚拟机等云资源，并用于对云服务进行身份验证。应用程序可以访问实例元数据服务 (IMDS) 以获取身份令牌。访问 Kubernetes Pod 的攻击者可以利用对 IMDS 端点的访问权限来获取托管身份的令牌，然后访问云资源。

6-恶意准入控制器

攻击者可能利用 Kubernetes 内置的通用恶意准入控制器（例如 ValidatingAdmissionWebhook）来访问凭据。该控制器的行为由集群中部署的准入 Webhook 决定。攻击者可以使用此 Webhook 拦截对 API 服务器的请求，或记录机密和其他敏感信息。

攻击者使用大量发现技术来探索他们已访问的 Kubernetes 环境。他们的目标可能是实现跨环境的横向移动并获得集群内部或外部的额外资源。有些技术允许他们访问 Kubernetes API 服务器或 Kubelet API，而另一些技术则使他们能够通过 Kubernetes 仪表板或云实例元数据映射集群网络或破坏资源。

1-访问K8s API服务器

Kubernetes API 服务器是一个关键组件，充当 Kubernetes 控制平面的前端或网关。它公开了 Kubernetes RESTful API，允许在集群中执行各种操作。API 服务器还检索集群的状态，包括部署在其上的所有组件。获得此 API 服务器访问权限的攻击者可以发送 API 请求来探测集群并检索有关其资源的信息和机密。

2-访问 Kubelet API

Kubelet 是安装在每个 Kubernetes 节点上的代理，可确保分配给该节点的 Pod 正确执行。它公开了一个只读 API 服务，不需要在 TCP 端口 10255 上进行身份验证。具有主机网络访问权限的攻击者可以通过 API 请求查询 Kubelet API，以检索主机上正在运行的 pod 以及有关主机的信息，例如CPU 和内存消耗。

3-网络映射

默认情况下，Kubernetes 不限制 Pod 之间的网络流量（通信）。攻击者可以利用这一事实。如果他们获得对单个容器的访问权限，他们可以使用它来探测集群网络、映射它并发现有关正在运行的 Pod/应用程序的信息，包括扫描已知漏洞。

4-访问 Kubernetes 仪表板

Kubernetes Dashboard 用于监控和管理 Kubernetes 集群。用户可以使用由其服务帐户的绑定或集群绑定确定的权限在集群中执行操作。但是，有权访问集群中单个容器的攻击者随后可以访问 Kubernetes 仪表板，并使用其身份检索有关集群资源的信息。

5-实例元数据API

云提供商提供元数据服务来检索有关虚拟机 (VM) 的信息，包括其网络配置、底层主机、磁盘、SSH 公钥和敏感凭据。VM 只能从 VM 内部通过不可路由的 IP 地址访问此服务。如果攻击者能够访问此元数据，他们可能能够利用它来访问或破坏容器或云资源。

攻击者在发生漏洞后使用横向移动技术在受害者的环境中移动。目标通常是访问其他资源，例如其他容器或节点。在容器化环境中，他们可能会尝试从对一个容器、从容器到底层节点或云环境的给定访问来访问集群中的各种资源。

1-访问云资源

在这种技术中，攻击者可以访问单个容器来破坏它，然后从这个受到破坏的容器转移到云环境及其资源。

2-容器服务帐号

默认情况下，Kubernetes 中的服务帐户 (SA) 会挂载到集群中的每个 Pod。它允许容器向 Kubernetes API 服务器发送请求。获得 Pod 访问权限的攻击者可以获得 SA 令牌，以向 API 服务器发送请求，并获得对集群中其他资源的访问权限。如果启用 RBAC，SA 权限由与其关联的角色绑定决定。但如果未启用 RBAC，SA 令牌将授予攻击者对集群的完全访问权限。

3-集群内部网络

默认情况下，Kubernetes 不限制集群中 Pod 之间的网络流量（通信）。如果攻击者获得对单个容器的访问权限，他们可能会使用受感染的容器来扩展其网络可达性，并获得对集群中其他容器、pod 和应用程序的访问权限。

4-配置文件中的应用程序凭据

机密存储在 Kubernetes 配置文件中，例如作为 pod 配置中的环境变量。如果攻击者有权访问这些配置，他们可能能够窃取这些机密，并使用它们来访问集群内部和外部的资源。

5-在主机上挂载可写卷

在此技术中，hostPath 卷将文件或目录安装到容器。攻击者可能会尝试从受感染的容器获取对底层主机的访问权限，并持续驻留在容器主机上。

6-CoreDNS投毒

CoreDNS 是 Kubernetes 中使用的主要域名服务器 (DNS) 服务。它的配置可以通过名为 corefile 的文件进行修改，该文件存储在位于 kube-system 命名空间的 ConfigMap 对象中。有权修改 ConfigMap（例如，通过使用容器的服务帐户）的攻击者可以更改集群 DNS 的行为，进行DNS投毒，并获取其他服务的网络身份。

7-ARP投毒和IP欺骗

Kubernetes 有多个容器网络接口（CNI）——可以在集群中使用的网络插件。通常，默认的网络插件是 Kubenet。在此配置中，在每个节点 (cbr0) 上创建一个网桥。各种 pod 使用 veth 对连接到节点。

网桥是一个二级组件，承载跨 Pod 流量，这使得集群中的 ARP 中毒成为可能。有权访问集群中某个 Pod 的攻击者可以执行 ARP 投毒，并欺骗其他 Pod 的流量。它们可以在网络级别执行多种攻击，从而导致横向移动，例如 DNS 欺骗或窃取其他 Pod 的云身份。

在 Kubernetes 中，攻击者使用收集技术从集群中或通过使用集群来收集信息。缓解此类攻击的一种方法是对 Kubernetes 中使用的仓库凭据实施只读策略。

1-私有仓库镜像

集群中运行的镜像可以存储在私有仓库中。要提取这些镜像，容器运行时引擎必须具有仓库的有效凭据。如果仓库由云提供商托管，则会使用云凭据进行身份验证。但是，如果攻击者能够访问集群，他们也许能够访问私有仓库并提取其镜像。一种方法是通过利用 Kubernetes pod 对 IMDS 端点的访问来使用托管身份令牌。

攻击者使用影响力技术来破坏、滥用或扰乱目标环境及其资源和活动的正常行为。

1-数据销毁

攻击者可能会尝试删除或移除 Kubernetes 集群中的资源。这些资源可能包括部署、配置、节点、pod、存储、计算或其他数据。

2-资源劫持

在这种技术中，攻击者试图劫持和滥用 Kubernetes 资源，以达到最初目的之外的目的。一个例子是使用受损的容器来运行恶意任务，例如数字货币挖掘（加密），也称为“加密劫持”攻击。

3-拒绝服务

攻击者可能会试图使合法用户无法使用服务。它们可能会影响 Kubernetes 控制平面内组件的可用性，例如 API 服务器、集群节点或 Pod 中的应用程序组件。

K8s渗透路线一般为：docker user shell -> docker root shell -> docker逃逸到node -> node横向至master

由于docker的user/root shell和常规的应用服务攻击手法相似，不做赘述。只提及docker逃逸到node、node横向至master。

逃逸技术主要有配置不当和漏洞利用。

不安全的配置：

1-容器组件未鉴权

- kube-apiserver: 6443, 8080

- kubectl proxy: 8080, 8081

- kubelet: 10250, 10255, 4149

- dashboard: 30000

- docker api: 2375

- etcd: 2379, 2380

- kube-controller-manager: 10252

- kube-proxy: 10256, 31442

- kube-scheduler: 10251

- weave: 6781, 6782, 6783

- kubeflow-dashboard: 8080

2-特权容器

意味着拥有所有Linux Capability权限。Capability权限是有一个集合的概念的，即一个进程或可执行文件，它可以拥有哪些特权的集合，其中就存在一些高危权限。

3-Capability权限过大

- SYS_ADMIN：即允许执行系统管理任务，如加载或卸载文件系统、设置磁盘配额等

- SYS_PTRACE：即允许跟踪任何进程

- SYS_MODULE：即允许插入和删除内核模块

4-特殊路径挂载

- /var/run/docker.sock

- /proc/sys/kernel/core_pattern

- /etc/

- /root/

- /home/user/

- 等

漏洞利用：

1-Docker 自身漏洞

- cve-2017-1002101

- cve-2018-1002100

- cve-2018-15664 符号链接替换漏洞

- cve-2019-14271 加载不受信任的动态链接库

- cve-2019-1002101

- cve-2019-11246

- cve-2019-11249

- cve-2019-11251

- cve-2019-16884

- cve-2019-5736 runc 逃逸

- cve-2020-15257

- cve-2020-27151

- kata-escape-2020

- cve-2021-25741

- cve-2021-30465

- cve-2022-0492

2-内核漏洞

- cve-2016-5195 DirtyCow

- cve-2017-1000112

- cve-2020-14386

- cve-2021-22555

- cve-2022-0847 DirtyPipe

可以利用创建具有不安全配置的Pod横向移动到master，而污点和污点容忍度是获取master节点的关键所在。

污点（Taint）和容忍度（Toleration）：

节点亲和性 是Pod的一种属性，它使 Pod 被吸引到一类特定的节点。污点（Taint）则相反——它使节点能够排斥一类特定的 Pod。容忍度（Toleration）是应用于 Pod 上的，允许（但并不要求）Pod 调度到带有与之匹配的污点的节点上。我们可以控制Pod创建时候的污点来向集群内的节点进行喷射创建。

Master节点的容忍度，默认为NoSchedule（节点不可调度）。

当节点拥有创建容器节点的权限时，通过类似下面的yaml文件，可以将节点部署在master节点中。

nginx.yaml

apiVersion: apps/v1kind: Deploymentspec:    spec:      containers:      - image: ubuntu/nginx:latest        name: myapp2        volumeMounts:        - mountPath: /host          name: host      dnsPolicy: ClusterFirst      restartPolicy: Always      schedulerName: default-scheduler      tolerations:      - effect: NoSchedule        key: node-role.kubernetes.io/master        operator: Exists      - effect: NoExecute        key: node-role.kubernetes.io/etcd        operator: Exists      volumes:      - hostPath:          path: /          type: Directory        name: host

如下图，可以发现nginx会部署在k8s-master0的主节点中。

CDK：https://github.com/cdk-team/CDK/releases/

CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

kdigger：https://github.com/quarkslab/kdigger

kdigger是Kubernetes digger的缩写，是用于 Kubernetes 渗透测试，内置 20+ bucket插件，以便于从 pod 内部对 Kubernetes 进行渗透测试。

kubeaudit：https://github.com/Shopify/kubeaudit

KubeAudit是命令行工具，也是审核Kubernetes群集的GO软件包，以解决各种不同的安全问题

1. https://devopscube.com/kubernetes-architecture-explained/

2. https://blog.csdn.net/QcloudCommunity/article/details/125650918

3. https://www.weave.works/blog/mitre-att-ck-matrix-for-kubernetes-tactics-techniques-explained-part-1

4. https://www.weave.works/blog/mitre-att-ck-matrix-for-kubernetes-tactics-techniques-explained-part-2

5. https://www.weave.works/blog/mitre-att-ck-matrix-for-kubernetes-tactics-techniques-explained-part-3

6. https://www.freebuf.com/column/233727.html

7. https://wiki.teamssix.com/CloudNative/

8. https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Kubernetes

9. https://mp.weixin.qq.com/s?__biz=MzkxMjI3MDgwOA==&mid=2247483918&idx=1&sn=97ae72dc1fbabefb2b19355592ef5a6a&scene=21#wechat_redirect