常见容器安全威胁来源于构建环境安全、运行时安全、操作系统安全、编排管理安全等，参考下图阿里云云上容器ATT&CK攻防矩阵，进行体系化研究：
通过容器管理服务获取对容器集群的访问或命令执行权限，是最典型的容器攻击场景之一。
常见服务：
-
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
上述组件的分工：
-
用户与 kubectl 或者 Kubernetes Dashboard 进行交互，提交需求。（例: kubectl create -f pod.yaml）;
-
kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https;
-
apiserver 会协同 ETCD 等组件准备下发新建容器的配置给到节点，协议：http/https（除 ETCD 外还有例如 kube-controller-manager, scheduler 等组件用于规划容器资源和容器编排方向，此处简化省略）;
-
apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
-
kubelet 与 Docker 等容器引擎进行交互，创建容器，协议：http/unix socket.
显而易见，每个组件的可控性失衡都潜藏着特定的风险与危害，并提供了潜在的利用途径。对于各类组件安全性的周密考量，除却各具特色的权限验证设计之外，网络隔离同样至关重要。传统的iptables配置和策略，在容器网络环境中亦能发挥其强大功效（实际上，许多容器网络的功能实现正是基于iptables机制构建）。
此外，我们无法忽视在容器领域中两种特色显著的安全方案：一是精心设计及实施Network Policy，它能够在容器、POD以及服务层面提供更为精细且优雅的网络管理与控制；二是采用服务网格技术，通过这一手段能够精准地驾驭集群内部流量，确保容器间通讯的高度安全与效能优化。
接下来，我们将逐一深入剖析这些核心组件的技术资料及其对应的渗透测试手法，以期全方位揭示其内在安全机制与可能存在的脆弱点。
01
apiserver
在红队战略解析框架下，Kubernetes APIServer 被视为集群架构的中枢神经系统核心组件，承载着无可替代的战略地位。它作为 Kubernetes 生态体系中至关重要的数据交换枢纽与控制平面的核心元素，扮演了犹如集群智能指挥中枢的关键角色，负责精密调度和协同管理各个计算资源节点间的联动操作。 
在针对 Kubernetes 集群的潜在攻击场景中，获取 administrative 级别的 kubeconfig 文件并掌控承载 apiserver 的 master 节点权限，乃是实现对系统最高控制权的关键性突破，相当于实质上触及了攻击的核心目标。
参考https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands，通过 apiserver 进行持续渗透和控制。因此如果想要攻击 apiserver, 必须确保容器内已安装有 kubectl ：
curl -LO "https://dl.Kubernetes.io/release/$(curl -L -s https://dl.Kubernetes.io/release/stable.txt)/bin/linux/amd64/kubectl"
默认情况下，apiserver 都是有鉴权的：
则可通过8080端口尝试未授权访问，服务启动：kube-apiserver –insecure-bind-address=0.0.0.0 –insecure-port=8080，此时请求接口的结果如下：
对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：
02
kubelet
在Kubernetes 的集群架构中，每一个 Node 节点均部署着一个至关重要的守护进程——kubelet，该组件持续监听并维护着诸如 10250、10248 及 10255 等核心端口的通信状态。其中，尤为关键的是 10250 端口，它扮演着 kubelet 与 apiserver 之间进行高效信息交互的中枢通道，承载了两者间的服务发现、资源调配及任务调度等主要通讯职责。通过此端口，kubelet 实时同步并执行由 apiserver 分发的待办工作负载，犹如一位忠实的管家，实时响应并贯彻集群控制平面下达的最新管理策略。
值得注意的是，在 Kubernetes 的最新迭代版本中，对对接至 10250 端口的访问行为已实施严格的鉴权管控机制，以确保数据交换的安全性。然而，在特定的应用场景下，如果启用了接纳匿名请求的功能配置，理论上未经认证的身份也可尝试通过 10250 端口发起通信请求，但此举明显违背了 Kubernetes 强调的安全最佳实践，因此应谨慎对待：
如果 10250 端口存在未授权访问漏洞，那么我们可以先使用 /pods 接口获取集群的详细信息，如 namespace，pods，containers 等
之后再通过curl -k https://Kubernetes-node-ip:10250/run/// -d “cmd=id” 的方式在任意容器里执行命令
此时，选择我们所有控制的容器快速过滤出高权限可逃逸的容器就很重要，在上述 /pods API 中可以获取到每个 POD 的配置，包括了 host*、securityContext、volumes 等配置，可以根据容器逃逸知识快速过滤出相应的 POD 进行控制。
由于这里 10250 鉴权当前的 Kubernetes 设计是默认安全的，所以 10255 的开放就可能更加容易在红蓝对抗中起到至关重要的作用。10255 本身为只读端口，虽然开放之后默认不存在鉴权能力，无法直接利用在容器中执行命令，但是可以获取环境变量 ENV、主进程 CMDLINE 等信息，里面包含密码和密钥等敏感信息的概率是很高的，可以快速帮我们在对抗中打开局面。
03
dashboard
Dashboard 是 Kubernetes 官方提供的用于图形化管控 Kubernetes 集群的核心组件。在特定情况下，如因 Kubernetes 配置不当导致 Dashboard 存在未授权访问漏洞时，攻击者可能利用此漏洞对整个 Kubernetes 集群进行完全控制。
默认状态下，Dashboard 内置了一套健全的身份验证机制，用户可通过kubeconfig 文件或基于 Token 的认证流程登录系统。当集群管理员启用了 enable-skip-login 功能选项后，用户在登录界面会看到一个“Skip”跳过登录的按钮，点击该按钮即可在未经严格身份验证的情况下直接进入 Dashboard。这种方式虽提供了操作上的便捷性，但需注意其潜在的安全风险，建议在生产环境中谨慎使用并确保合理的权限管控措施已经落实到位。
当用户选择跳过身份验证过程并通过点击 “Skip” 进入 Kubernetes 面板时，默认情况下，其操作权限受限于 Kubernetes 引入的 RBAC（基于角色的访问控制）机制。该机制通过服务账户（ServiceAccount）来实现精细的身份验证和授权管理，在不同的 ServiceAccount 之间分配差异化的集群操作权限。
实际上，当我们“Skip”登录并直接进入 Kubernetes Dashboard 时，系统默认使用的是名为 “Kubernetes-dashboard” 的 ServiceAccount。若此 ServiceAccount 未经额外权限配置，将不具备对集群进行全面功能操作的能力。
然而，在部分开发场景或测试环境中，为便于管理或调试，开发者可能会赋予 Kubernetes-dashboard ServiceAccount 与 cluster-admin 这一 ClusterRole 相关联的权限。cluster-admin 是一个拥有集群最高管理权限的角色，将其绑定至 Kubernetes-dashboard，意味着该 Dashboard 将能执行所有集群资源的管理操作。
具体设置如下：
-
新建 dashboard-admin.yaml 内容如下（该配置也类似于 “利用大权限的 Service Account” 一小节的配置 ）
-
执行 kubectl create -f dashboard-admin.yaml，此时用户通过点击 Skip 进入 dashboard 即可拥有管理集群的权限了。
进入到 dashboard 我们可以管理 Pods、CronJobs 等，创建 Pod 控制 node 节点方法如下：
新建以下配置的 Pod，该 pod 主要是将宿主机根目录挂载到容器 tmp 目录下。
之后可通过该容器的 tmp 目录管理 node 节点的文件
值得注意的是，为了集群的稳定性和安全性要求，在 Kubernetes 默认设计的情况下 Pod 是不能调度到 master 节点的，但如果用户自行设置关闭了 Master Only 状态，那么我们可以直接在 master 节点新建 Pod 更直接的控制 master node；不过目前各大主流云产商上的 Kubernetes 集群服务，都会默认推荐让 Master 节点由云厂商托管，更加加剧了 Master 节点渗透和控制的难度。
04
etcd
etcd作为一种分布式的键值存储系统，被广泛应用在各类分布式系统架构和机器集群中以持久化数据，其默认监听2379等端口进行通信。若该端口直接暴露于公网环境，可能导致敏感信息泄露风险增加。本文着重探讨因配置错误导致Kubernetes集群中etcd服务面临未授权访问的问题。
在Kubernetes环境中，默认采用了etcd v3版本用以存储核心的集群配置和状态数据，因此，一旦攻击者能够非法获取并操控etcd服务，理论上即等同于完全控制了整个Kubernetes集群。
在Kubernetes的运维过程中，用户可通过编辑/etc/kubernetes/manifests/etcd.yaml配置文件来调整etcd Pod的相关参数设定。假定管理员在配置更新时，不慎将etcd的监听地址设置为0.0.0.0，从而使其对任意网络来源开放，那么攻击者便有可能利用这一漏洞，未经授权地从etcd中获取用于Kubernetes认证鉴权的token，进而实施对集群的非法控制操作。方式如下：
首先读取用于访问 apiserver 的 token：
利用 token 可通过 apiserver 端口 6443 控制集群：
05
docker remote api
Docker Engine API 是 Docker 提供的基于 HTTP 协议的用于 Docker 客户端与 Docker 守护进程交互的 API，Docker daemon 接收来自 Docker Engine API 的请求并处理，Docker daemon 默认监听 2375 端口且未鉴权，我们可以利用 API 来完成 Docker 客户端能做的所有事情。
Docker daemon 支持三种不同类型的 socket: unix, tcp, fd。默认情况下，Docker daemon 监听在 unix:///var/run/docker.sock，开发者可以通过多种方式打开 tcp socket，比如修改 Docker 配置文件如 / usr/lib/systemd/system/docker.service：
之后依次执行 systemctl daemon-reload、systemctl restart docker 便可以使用 docker -H tcp://[HOST]:2375 这种方式控制目标 docker
因此当你有访问到目标 Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用 Docker API 在远程主机上创建一个特权容器，并且挂载主机根目录到容器，对主机进行进一步的渗透，更多利用方法参考容器逃逸章节。
检测目标是否存在 docker api 未授权访问漏洞的方式也很简单，访问 http://[host]:[port]/info 路径是否含有 ContainersRunning、DockerRootDir 等关键字。
06
kubectl proxy
kubectl的proxy子命令在实际场景中相对较少被直接触达，此处特将其单独剖析。鉴于当前主流开源分支中的Kubernetes核心组件，如API Server、Controller Manager和Scheduler等，在鉴权机制方面已默认具备较强的安全性，因此因配置不当引发安全问题的情况相对较少，且企业内部通常对内外网访问权限有着严格的管控措施。然而，kubectl proxy在此背景下却成为一个值得注意且易于遭受恶意利用的潜在安全薄弱点。
对于熟悉Kubernetes平台的用户而言，当在一个Pod上暴露端口并使用ClusterIP类型Service进行内部绑定时，默认情况下，若未通过NodePort或LoadBalancer类型的Service对外提供服务，则集群外部无法直接访问到该内部服务（除非进行了针对网络插件如CNI的深度定制和配置修改）。
换言之，kubectl proxy作为一项功能，能够代理用户对集群内受限资源的访问，这在一定程度上可能成为攻击者绕过集群外网访问限制、实现非法入侵的有效途径，值得运维人员给予高度关注与严谨配置。
如果想临时在本地和外网调试的话，kubectl proxy 似乎是个不错的选择。
但其实 kubectl proxy 转发的是 apiserver 所有的能力，而且是默认不鉴权的，所以 –address=0.0.0.0 极其危险。
Kubectl是用于对Kubernetes（k8s）集群进行集中管控的命令行界面工具，它在用户的主目录$HOME/.kube中定位并引用名为config的配置文件，该文件包含了与集群API Server进行安全认证和交互所需的参数。通过利用kubectl exec子命令，攻击者能够在任意Pod容器内部执行自定义命令，从而实现对集群资源的潜在恶意操控。
示例：kubectl exec进入pod内部执行指令：
root@linux> kubectl get podNAME READY STATUS RESTARTS AGEapp-1-wp-0 1/1 Running 0 182dapp-1-wp-1 1/1 Running 0 182dmyapp 1/1 Running 0 11dmyappnew 1/1 Running 0 11droot@linux> kubectl exec -it myappnew /bin/bashroot@myappnew:/# whoamiroot
查看类命令：
#获取节点和服务版本信息kubectl get nodes#获取节点和服务版本信息，并查看附加信息kubectl get nodes -o wide# 获取pod信息，默认是default名称空间kubectl get pod# 获取pod信息，默认是default名称空间，并查看附加信息【如：pod的IP及在哪个节点运行】kubectl get pod -o wide# 获取指定名称空间的podkubectl get pod -n kube-system# 获取指定名称空间中的指定podkubectl get pod -n kube-system podName# 获取所有名称空间的podkubectl get pod -A# 查看pod的详细信息，以yaml格式或json格式显示kubectl get pods -o yamlkubectl get pods -o json# 查看pod的标签信息kubectl get pod -A --show-labels# 根据Selector（label query）来查询podkubectl get pod -A --selector="k8s-app=kube-dns"# 查看运行pod的环境变量kubectl exec podName env# 查看指定pod的日志kubectl logs -f --tail 500 -n kube-system kube-apiserver-k8s-master# 查看所有名称空间的service信息kubectl get svc -A# 查看指定名称空间的service信息kubectl get svc -n kube-system# 查看componentstatuses信息kubectl get cs# 查看所有configmaps信息kubectl get cm -A# 查看所有serviceaccounts信息kubectl get sa -A# 查看所有daemonsets信息kubectl get ds -A# 查看所有deployments信息kubectl get deploy -A# 查看所有replicasets信息kubectl get rs -A# 查看所有statefulsets信息kubectl get sts -A# 查看所有jobs信息kubectl get jobs -A# 查看所有ingresses信息kubectl get ing -A# 查看有哪些名称空间kubectl get ns# 查看pod的描述信息kubectl describe pod podNamekubectl describe pod -n kube-system kube-apiserver-k8s-master# 查看指定名称空间中指定deploy的描述信息kubectl describe deploy -n kube-system coredns# 查看node或pod的资源使用情况# 需要heapster 或metrics-server支持kubectl top nodekubectl top pod# 查看集群信息kubectl cluster-info 或 kubectl cluster-info dump# 查看各组件信息【172.16.1.110为master机器】kubectl -s https://172.16.1.110:6443 get componentstatuses
操作类命令：
# 创建资源kubectl create -f xxx.yaml# 应用资源kubectl apply -f xxx.yaml# 应用资源，该目录下的所有 .yaml, .yml, 或 .json 文件都会被使用kubectl apply -f <directory># 创建test名称空间kubectl create namespace test# 删除资源kubectl delete -f xxx.yamlkubectl delete -f <directory># 删除指定的podkubectl delete pod podName# 删除指定名称空间的指定podkubectl delete pod -n test podName# 删除其他资源kubectl delete svc svcNamekubectl delete deploy deployNamekubectl delete ns nsName# 强制删除kubectl delete pod podName -n nsName --grace-period=0 --forcekubectl delete pod podName -n nsName --grace-period=1kubectl delete pod podName -n nsName --now# 编辑资源kubectl edit pod podName
攻击者可通过拥有pods权限的用户创建基础镜像并利用其执行后续渗透操作。
通过yaml文件创建pod，并将pod的根目录/挂载到容器/mnt目录下，操作宿主机文件：
cat mymaster.yamlapiVersion: v1kind: Podmetadata:name: myappnewspec:containers:image: nginxname: containervolumeMounts:mountPath: /mntname: test-volumevolumes:name: test-volumehostPath:path: /kubectl create -f ~/Desktop/test/mymaster.yamlcreatedkubectl exec -it myappnew /bin/bash:/# cd /mnt:/mnt# lsbin checkapp etc lib lost+found mnt proc run srv tmp varboot dev home lib64 media opt root sbin sys usr
在 Kubernetes 集群中，一组核心的控制循环组件，即控制器(Controllers)，持续不断地运作以确保集群的实际状态与用户定义的预期状态保持一致。具体而言，例如 ReplicaSet 控制器承担着维护系统中运行 Pod 实例数量精确符合设定规格的职责；而 Node 控制器则专注于监控各个节点的健康状况和可用性，并能在检测到节点故障时迅速执行相应的故障恢复操作。
在具备对控制器资源进行操作的权限背景下，攻击者能够利用 ReplicaSet、DaemonSet 或 Deployment 等控制器机制，通过创建并持久化特定容器，从而植入后门程序，实现对集群环境的持续控制与渗透。
攻击者通过controllers攻击：
cat nginx-deploy.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: nginx-deploymentlabels:app: nginx-testspec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:image: nginxname: containervolumeMounts:mountPath: /mntname: test-volumevolumes:name: test-volumehostPath:path: /kubectl apply -f nginx-deploy.yamlcreatedkubectl get podsNAME READY STATUS RESTARTS AGE1/1 Running 0 183d1/1 Running 0 183dmyapp 1/1 Running 0 12dmyappnew 1/1 Running 0 38m1/1 Running 0 55s
在Kubernetes集群中，系统架构上区分了用户身份(User Account)和服务账号(Service Account)两类账户体系。其中，用户账户主要用于管理员与集群间的交互操作和管理授权，确保符合权限控制原则；而服务账号则是为Pod内部进程设计的特殊实体，用于在容器环境下安全、可靠地调用Kubernetes API或者其他外部服务资源。
Kubernetes默认为每个Pod提供一个关联的服务账户，并将该账户的访问凭证自动注入到Pod容器中。然而，若某一Pod因安全漏洞遭受入侵，并且其所关联的服务账户拥有较高的权限等级，则攻击者理论上可在容器内部环境中，利用获取到的服务账户凭证直接向Kubernetes API服务器发起指令操作，从而对集群造成潜在威胁与风险。
示例：service account在容器内部的默认路径：
cd /var/run/secrets/kubernetes.io/serviceaccount示例：带凭证访问API server的方式：
curl -voa -s https://192.168.0.234:6443/version# 以下命令相当于 kubectl get nocurl -s https://192.168.0.234:6443/api/v1/nodes?watch --header "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tOGprZmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2DydmljZS1hY2NvdW50LnVpZCI6Ijg4Y2ZmNmYzLWY0NzktMTFlOS1iZmY1LTJlYzU3MmZlMWRjOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.OU740qNcSf0Z__vAO1XJWUw9fvNNI2e4LxHypkpzREmnqrK9UZ-rrp9tG8Vxbc65FlPFj9efdpfWYExxjDDQwQTi-5Afmk4EA6EH-4vEs4V1r4gb0za8cyPVSAjzmEh7uIMgQHVo7y32V_BqUd8cmBoTdgnTY8Nx2QvMClvoYvEWvDKhbMnQjWH1x5Z6jK0iNg7btlK_WXnz8-yU2a0-jgoZFZ8D_qX16mZJ_ZoxEwPNTeNR8pP1l3ebZGVqBQA1PIFVG4HOlYomZya_DWGleMRYpulnECtBOTYyswzCwN8qJUVsdv6yWH1blWHKzYrkcoDmp2r6QhekaG1KFoX_YA" --cacert ca.crt
在采用SSH服务的容器环境中，新的安全风险面得以显现。当此类容器遭遇暴力破解或登录凭据泄露事件时，攻击者能够成功渗透并执行恶意指令，对容器内部进行操控。这种情况在自建容器环境或Kubernetes（简称K8s）集群中尤为常见，尤其当运维人员将容器作为虚拟机（VM）类似资源进行管理时，容易忽略由此引入的安全隐患。
进一步而言，在攻击者实现逃逸至宿主机（node节点）的情况下，他们可通过植入账户信息、篡改或注入/.ssh/authorized_keys文件等手段，利用SSH协议通道实施持续控制并下发一系列恶意指令。这一过程凸显了容器安全防护的迫切性，要求对基于SSH访问机制的权限管理和凭证保护采取更为严谨和高级的专业策略。
在云服务环境中，针对虚拟机（VM）和容器服务的管理，云服务商广泛采用了沙箱化的高效管理工具以提升用户操作体验与运维效率。这种机制旨在通过构建独立、隔离的运行环境，确保每个用户的服务实例能够安全、稳定地运行，且不会相互干扰。例如，阿里云、AWS等知名云服务商均提供了功能齐全、易用性高的API和控制台界面，使用户能够轻松部署、配置和监控VM及容器集群。
然而，这种便捷性同时也带来了一定的安全隐患。一旦用户的云账号凭证遭到泄露，攻击者就有可能利用云厂商提供的强大API接口，对用户的整个资源体系进行恶意接管，包括但不限于VM和容器集群。他们可以借此执行未经授权的操作，如创建、删除或篡改资源，进而导致数据泄露、服务中断甚至业务瘫痪等一系列严重的安全事件。
同时，不可忽视的是云厂商沙箱自身可能存在安全漏洞或设计缺陷。如果这些潜在的风险被攻击者利用，那么即使用户的账号凭证安全无虞，其托管在云端的集群也可能因此受到威胁。比如，沙箱逃逸漏洞的存在可能会使得原本应隔离运行的环境发生交叉污染，从而破坏集群内部的安全边界，对用户的核心业务构成直接冲击。
示例：通过Cloud Shell管理集群：
在容器化环境中，所谓的流氓容器是指那些处于计划外或未经官方授权与批准的容器实例。这一现象在开发环节尤为常见，当应用开发者为测试代码而自行启动临时容器时，往往容易导致此类情况的发生。然而，若这些非正式容器未经过严谨的漏洞扫描以及恰当的安全配置，其被恶意利用的风险将显著增加。
因此，流氓容器对组织机构构成了额外的安全隐患，特别是当它们存在于环境当中，却并未被开发团队和安全管理人员有效觉察和管控的情况下，这无疑形成了一个潜在的安全盲区或者说灰色地带，对整个系统的安全性构成挑战。
Apache APISIX 是一款采用 Lua 语言开发的动态、实时、高效能 API 网关解决方案，它提供了全面的流量管理功能，涵盖了负载均衡、动态上游服务发现、灰度发布、服务熔断、身份验证以及可观测性等核心领域。
APISIX 内建了 RESTful 风格的 Admin API 接口，用户可以通过这些接口实现对 APISIX 的精细化配置与管理。初始状态下，该 Admin API 只允许本地主机（127.0.0.1）进行访问。但用户可以根据实际需求，在 conf/config.yaml 配置文件中的 ‘allow_admin’ 字段中指定可调用 Admin API 的授权 IP 地址列表，以扩展远程管理功能。
然而，当用户选择对外开放 Admin API 并且未对预设的默认 admin_key 进行更改时，潜在的安全隐患将会显现。攻击者在获取此硬编码的默认密钥后，将有可能利用其执行任意的 Lua 脚本代码，从而对系统实施恶意操作或攻击。因此，强烈建议用户在启用 Admin API 的同时，务必修改并使用安全强度高的自定义 admin_key，以确保系统的安全性与稳定性。
根据 apisix 官方文档可以知道，在创建路由时用户可以定义一个 filter_func 参数用于处理请求，filter_func 的内容可以是任意的 lua 代码。
那么我们便可以使用默认的 admin_key 创建恶意的 route 并访问以触发 lua 代码执行，达到 rce 的目的，下面是具体步骤：
（1）创建可用的 services:
（2）创建恶意的 route:
最后访问 http://127.0.0.1:9080/api/tforce_test 即可触发预定义的 lua 代码执行。因此，在内网里攻击云原生 API 网关是比较容易打开一定局面的。
福利来啦！！！
东方隐侠在参加知识大陆官方年终活动，敬请参加：
原文始发于微信公众号（东方隐侠安全团队）：第五节：云上容器安全威胁（二）执行
