云靶场搭建–Kubernetes Goat

这里在本机部署,得先安装docker,我使用的是mac的orbstack,windows安装Docker-Desktop

Mac:

Homebrew 安装kubectl

安装 kubectl (K8s 的命令行工具,相当于遥控器)
brew install kubectl

安装 Helm (K8s 的包管理器,Goat 依赖它来安装)
brew install helm

安装 Kind (用来在 Docker 容器里跑 K8s 集群)
brew install kind

启动本地 K8s 集群

使用 Kind 创建一个单节点的集群:

Bash

kind create cluster --name k8s-goat

看见 “Cluster “k8s-goat” created” 字样即表示成功。

检查一下集群状态:

kubectl cluster-info
kubectl get nodes

状态应该是 Ready

kubectl_status

一键部署 Kubernetes Goat

接下来把漏洞环境“注入”到你的集群里。

1、克隆代码

git clone https://github.com/madhuakula/kubernetes-goat.git
cd kubernetes-goat

2、运行安装脚本:

./setup-kubernetes-goat.sh

如果脚本报错,可以直接用 kubectl 安装:

kubectl apply -f https://raw.githubusercontent.com/madhuakula/kubernetes-goat/master/deploy/k8s-goat.yaml

3、确认部署成功:

kubectl get pods -A

你会看到一大堆 Pod(比如 system-monitor, hidden-in-layers 等)正在启动。等它们的状态都变成 Running

kubectl_get_pods

Windows:

wget/winget:

winget安装 kubectl

PowerShell

winget install -e --id Kubernetes.kubectl

安装 Helm

PowerShell

winget install -e --id Helm.Helm

安装 Kind

PowerShell

winget install -e --id Kubernetes.kind

启动本地 K8s 集群

这一步与 Mac 基本一致,但要注意 Docker 权限。

1、确保 Docker Desktop 正在运行,且设置为 Linux Containers 模式。

2、使用 Kind 创建集群:

PowerShell

kind create cluster --name k8s-goat

3、检查状态:

PowerShell

kubectl cluster-info

如果报错“无法连接服务器”,就是是 Docker 没启动或者 kubeconfig 没自动配置好。重新运行部署脚本即可。

访问靶场

Kubernetes Goat 的设计比较特别,它模拟的是内部微服务。要攻击它们,你需要把这些服务“映射”到你的本机端口。

由于Kubernetes Goat 靶场运行在docker,并且k8s内部模拟服务,因此想要访问得到就需要对端口进行映射。

最简单的方法(一键映射所有靶场):直接运行access-kubernetes-goat.sh这个脚本

./access-kubernetes-goat.sh

access_kube_goat

现在浏览器访问127.0.0.1:1234

access_lab

如果只想映射单个漏洞场景:

1.查看有哪些 Service
kubectl get svc
2.把内部的 health-check 服务映射到本地 1234 端口
kubectl port-forward svc/health-check 1234:80

然后打开浏览器访问 http://127.0.0.1:1234,就能看到漏洞页面了。

这里就不做了

下面梳理一下K8s各个部分的关系(用AI生成的)

k8s内部关系梳理

1. Node(节点):基础设施与宿主机

Node 就是真正干活的“服务器”(可以是物理机,也可以是虚拟机)。

  • Control Plane(控制平面/Master Node):这是集群的大脑或“老板”。它负责发号施令、调度资源、存储集群的所有状态(比如 etcdkube-apiserver)。
  • Worker Node(工作节点):这是“打工人”。负责真正运行你的应用程序代码。

在你的环境中:因为你使用的是 kind (Kubernetes in Docker),所以你的 Mac 上的 Docker 容器模拟了这些 Node。

2. Pod:K8s 的最小执行单元

Pod 是 K8s 里最小的“房间”。

  • K8s 不直接运行 Docker 容器,而是把一个或多个容器(通常是一个)打包进一个 Pod 里。
  • 同一个 Pod 里的容器共享网络(同一个 IP)和存储。

渗透视角:当你通过 Web 漏洞(比如 RCE)拿下一个 shell 时,你通常是落在一个 Pod 的容器里。你的首要目标往往是如何从这个“房间”逃出去(容器逃逸),从而控制整个 Node(宿主机)。

3. Deployment:Pod 的“包工头”

我们在上一个问题里提到过,你直接看到的往往不是单纯的 Pod,而是由 Deployment 管理的 Pod。

  • 如果一个 Pod 死掉了(程序崩溃、节点断电),Deployment 会立刻拉起一个新的 Pod 补上。
  • 这就是为什么你之前看到那么多带着随机后缀的 Pod(比如 system-monitor-deployment-xxxx),后缀就是包工头给新工人贴的工牌号。

4. Service (svc):稳定的“前台/通讯录”

这是 K8s 网络中最关键的概念。

  • 痛点:因为 Pod 随时会死掉并被 Deployment 重新拉起,每次新拉起的 Pod IP 地址都会变。如果其他服务想要访问它,总不能每次都去查新 IP 吧?
  • 解决:Service 就是一个具有固定 IP 和内部域名的“前台”。外界或其他 Pod 只需要访问 Service,Service 就会自动把流量作为一个负载均衡器,转发给背后存活的对应 Pod。

渗透视角:在内网横向移动时,攻击者通常会进行服务发现(Service Discovery),扫描这些固定的 svc 地址,看看集群内部有没有未授权的数据库或内部 API。


简单总结它们的串联关系:

  1. 开发者创建一个 Deployment
  2. Deployment 在某个 Node 上启动了几个 Pod(里面跑着业务容器)。
  3. 为了让别人能访问这些 Pod,创建了一个 Service (svc) 绑定它们。
  4. 用户请求到达 -> 被 Service 接收 -> 路由到某个具体的 Pod -> 由 Pod 内的容器处理响应。

既然梳理清了这层关系,在 Kubernetes Goat 这个靶场里,攻击路径通常是:打穿 Pod(Web 漏洞) -> 发现内部 Service(内网漫游) -> 窃取凭证或利用提权漏洞(Privilege Escalation) -> 控制整个 Node 或集群大脑。