Kubernetes Goat 场景 12 实战:通过容器环境变量获取 Kubernetes Secret 注入的敏感凭据【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat本文围绕 Kubernetes Goat一个设计上就脆弱的 Kubernetes 靶场中的场景 12「Gaining environment information获取环境信息」展开。你将学会从一个容器内的 Web 终端出发用cat /proc/self/cgroup、cat /etc/hosts、mount、printenv等标准 Linux 手段完成一次完整的信息枚举最终定位到通过secretKeyRef注入容器环境变量的 Kubernetes Secret 凭据vault key并从源码与清单层面理解把密钥放环境变量这一常见反模式的风险本质。场景背景与目标在真实的生产环境中绝大多数计算实例在运行应用时都会把敏感信息secrets、API keys、配置值等存放在环境变量里。Kubernetes 场景 12 正是模拟了这种典型做法团队把 Kubernetes Secret本例中是一把 vault 的 API key以环境变量的形式注入 Pod。文档给出的背景判断是——如果攻击者找到应用漏洞如 RCE 远程代码执行或命令注入那么这些密钥基本宣告失守。场景的核心设定如下对应 场景 12 指南文档 与 集群内置引导页故事线Kubernetes 中的每个环境都有大量信息可被分享——secrets、API keys、configs、services 等任务就是找到那把 vault key。目标Goal拿到k8s_goat_flag的 flag 值即完成场景且文档明确提示这可以通过多种方式达成。提示Hint如果不知道环境变量存在哪里回到标准 Linux 工具比如env。完成后的收获1如何探索并分析容器环境变量2如何获取容器内的敏感信息。入口启动靶场后访问http://127.0.0.1:1233。场景环境架构:127.0.0.1:1233 背后是什么读懂场景的前提是弄清楚http://127.0.0.1:1233到底指向哪个工作负载、flag 又藏在哪里。从仓库源码可以确认以下链路1. 端口 1233 由访问脚本转发到 system-monitor Pod。在 access-kubernetes-goat.sh 中脚本通过kubectl get pods -l appsystem-monitor找到 Pod并执行kubectl port-forward $POD_NAME --address 0.0.0.0 1233:8080也就是说本地 1233 端口最终打到 Pod 内的 8080 端口。2. 8080 端口是一个免密 Web Shell。infrastructure/system-monitor/Dockerfile 基于ubuntu:noble安装了htop、curl等工具并下载 gotty一个把终端共享到浏览器的工具容器入口为EXPOSE 8080 CMD [ gotty, -w, bash ]gotty -w bash会在 8080 端口起一个 Web 页面任何人打开页面就能获得一个交互式 bash——这正是场景 12 的入口。它模拟的是攻击者已经拿到容器内执行权例如通过 RCE之后的视角。3. flag 的来源:secretKeyRef 注入的环境变量。在 scenarios/system-monitor/deployment.yaml 中定义了 SecretapiVersion: v1 kind: Secret metadata: name: goatvault namespace: default type: Opaque data: k8sgoatvaultkey: azhzLWdvYXQtY2QyZGEyNzIyNDU5MWRhMmI0OGVmODM4MjZhOGE2YzMDeployment 通过valueFrom.secretKeyRef把它注入容器env: - name: K8S_GOAT_VAULT_KEY valueFrom: secretKeyRef: name: goatvault key: k8sgoatvaultkey见 deployment.yaml 第 47-52 行对清单中的 base64 值解码即可验证 flagecho azhzLWdvYXQtY2QyZGEyNzIyNDU5MWRhMmI0OGVmODM4MjZhOGE2YzM | base64 -d # 输出: k8s-goat-cd2da27224591da2b48ef83826a86c3这串k8s-goat-cd2da27224591da2b48ef83826a86c3就是本场景要你在容器内找到的 vault key 值。4. 顺带一提的额外风险面。从源码结构看同一个 system-monitor Pod 还声明了hostPID: true、hostIPC: true、privileged: true并把宿主机根目录hostPath: /挂载到/host-system见 deployment.yaml 第 25-46 行。这些配置服务于仓库中后续的容器逃逸相关场景在场景 12 里你不需要用到它们但这也提醒读者真实环境中一个既暴露了 Web Shell、又带有特权容器配置的 Pod风险是叠加的。如何把环境跑起来使用仓库根目录的 setup-kubernetes-goat.sh 部署所有场景清单其中 第 85 行 部署了scenarios/system-monitor/deployment.yaml再运行 access-kubernetes-goat.sh 建立本地端口转发然后浏览器访问http://127.0.0.1:1233即可进入 Web 终端访问http://127.0.0.1:1234则是集群内的 Kubernetes Goat 主页goat-home本场景的任务说明页由 infrastructure/goat-home/home/content/scenario-12.md 渲染。实战演练:容器内信息枚举Method 1进入 Web Shell 后场景指南给出的方法是把容器探索一遍。以下命令与 场景 12 指南 中的 Solution Walkthrough 一一对应。1. 确认自己是否在容器里:cat /proc/self/cgroupcat /proc/self/cgroup输出中的 cgroup 层级路径docker/containerd 风格的层级与容器 ID能直接暴露容器运行时信息帮助判断隔离边界。2. 查看容器主机的基础信息cat /etc/hosts/etc/hosts会显示 Pod 的容器 ID、主机名与网络配置是确认我正处在一个被编排过的环境里的常用手段。3. 查看挂载信息mountmount输出可以揭示容器看到了哪些文件系统挂载对于 system-monitor 这类把宿主机根目录挂进来的 Pod这里的信息量尤其大也印证了清单中的hostPath配置。4. 探索文件系统ls -la /home/逐步翻看目录结构了解容器内有哪些账号、文件与工具判断还有哪些入口点。5. 关键一击:printenv列出全部环境变量printenv这是场景 12 的核心命令。printenv会输出当前进程的全部环境变量其中就包含 Deployment 通过secretKeyRef注入的K8S_GOAT_VAULT_KEY——也就是那把 vault keyflag 值k8s-goat-cd2da27224591da2b48ef83826a86c3。除此之外Kubernetes 还会自动注入一批环境变量服务发现变量、KUBERNETES_SERVICE_HOST/KUBERNETES_SERVICE_PORT等 API Server 地址等这些同样是攻击者做横向移动的线索。拿到该值即完成场景。文档提示可以以多种方式找到它从仓库证据可以印证其中两种其一就是上面的容器内枚举其二是不进容器、直接从集群侧读取——kubectl get secret goatvault并对 base64 值解码结果与容器内看到的一致。这恰恰说明当凭据的读取权限容器内进程或集群 API 权限被突破后注入方式本身并不提供额外保护。为什么环境变量是弱防线:风险分析与加固建议场景 12 的价值在于演示了一条非常短的攻击链能执行任意命令 能读到全部环境变量 能拿到密钥。从本仓库的实现看其根因可以归纳为几点环境变量对容器内任何进程可见。主进程、它 fork 出的任何子进程、乃至通过/proc/1/environ这类内核接口都可以读到同一份环境变量。一个无密码的 gotty Web Shell 足以演示这一点——场景中甚至没有 RCE拿到 shell这一步被靶场直接送给了玩家。secretKeyRef 只保护清单里的值不保护运行时的值。使用secretKeyRef时kubectl get pod -o yaml不会显示密钥明文但任何已执行进容器的进程都能直接printenv拿到明文Pod 清单层面的隐藏因此形同虚设。凭据生命周期与注入方式错配。环境变量在容器创建时一次性注入、进程存活期间常驻内存无法按次读取、无法细粒度授权、也无法在进程间共享之外被其他进程看见。对应的加固方向与本场景的风险点逐条对应避免把长期有效的 API key 放进环境变量优先使用以文件形式挂载的 Secret Volume可控制文件权限或改用外部密钥管理系统按需注入。场景 12 指南的 References 即指向了 Kubernetes Secrets 概念与 Vault Agent 以 sidecar 方式注入密钥的模式——后者正是短时效、按需获取的典型代表。收紧能进入容器的一切入口无认证的 Web 终端、调试 sidecar、宽松的exec权限都会把环境变量直接暴露给攻击者RBAC 应按最小权限授予本仓库另有场景演示了服务账号被赋予过宽权限导致 Secret 可被 API 读取的情形可对照 scenarios/hunger-check/deployment.yaml 中的secret-readerRole 理解权限模型。消除叠加风险面本例 Pod 同时带有privileged: true与宿主机根目录挂载环境变量泄漏只是第一层损失对监控类负载应使用只读根文件系统、非特权容器与最小化命名空间挂载。关键文件索引内容仓库相对路径场景 12 指南Overview/Goal/Hints/Solution Walkthroughguide/docs/scenarios/scenario-12/scenario-12.md集群内置场景说明页1234 主页展示的任务文案infrastructure/goat-home/home/content/scenario-12.md场景清单Secret goatvault secretKeyRef 环境变量注入scenarios/system-monitor/deployment.yamlWeb Shell 镜像gotty -w bashEXPOSE 8080infrastructure/system-monitor/Dockerfile部署脚本第 85 行部署 system-monitorsetup-kubernetes-goat.sh端口转发脚本1233:8080 指向 system-monitor Podaccess-kubernetes-goat.sh适用前提说明以上所有步骤与端口映射以当前仓库的脚本与清单为准本地 1233 端口转发依赖access-kubernetes-goat.sh先于浏览访问运行flag 值取自当前清单中的 base64 数据。靶场环境仅应在隔离的实验集群中部署请勿将其中任何脆弱配置带入生产。【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes Goat 场景 12 实战:通过容器环境变量获取 Kubernetes Secret 注入的敏感凭据【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat本文围绕 Kubernetes Goat一个设计上就脆弱的 Kubernetes 靶场中的场景 12「Gaining environment information获取环境信息」展开。你将学会从一个容器内的 Web 终端出发用cat /proc/self/cgroup、cat /etc/hosts、mount、printenv等标准 Linux 手段完成一次完整的信息枚举最终定位到通过secretKeyRef注入容器环境变量的 Kubernetes Secret 凭据vault key并从源码与清单层面理解把密钥放环境变量这一常见反模式的风险本质。场景背景与目标在真实的生产环境中绝大多数计算实例在运行应用时都会把敏感信息secrets、API keys、配置值等存放在环境变量里。Kubernetes 场景 12 正是模拟了这种典型做法团队把 Kubernetes Secret本例中是一把 vault 的 API key以环境变量的形式注入 Pod。文档给出的背景判断是——如果攻击者找到应用漏洞如 RCE 远程代码执行或命令注入那么这些密钥基本宣告失守。场景的核心设定如下对应 场景 12 指南文档 与 集群内置引导页故事线Kubernetes 中的每个环境都有大量信息可被分享——secrets、API keys、configs、services 等任务就是找到那把 vault key。目标Goal拿到k8s_goat_flag的 flag 值即完成场景且文档明确提示这可以通过多种方式达成。提示Hint如果不知道环境变量存在哪里回到标准 Linux 工具比如env。完成后的收获1如何探索并分析容器环境变量2如何获取容器内的敏感信息。入口启动靶场后访问http://127.0.0.1:1233。场景环境架构:127.0.0.1:1233 背后是什么读懂场景的前提是弄清楚http://127.0.0.1:1233到底指向哪个工作负载、flag 又藏在哪里。从仓库源码可以确认以下链路1. 端口 1233 由访问脚本转发到 system-monitor Pod。在 access-kubernetes-goat.sh 中脚本通过kubectl get pods -l appsystem-monitor找到 Pod并执行kubectl port-forward $POD_NAME --address 0.0.0.0 1233:8080也就是说本地 1233 端口最终打到 Pod 内的 8080 端口。2. 8080 端口是一个免密 Web Shell。infrastructure/system-monitor/Dockerfile 基于ubuntu:noble安装了htop、curl等工具并下载 gotty一个把终端共享到浏览器的工具容器入口为EXPOSE 8080 CMD [ gotty, -w, bash ]gotty -w bash会在 8080 端口起一个 Web 页面任何人打开页面就能获得一个交互式 bash——这正是场景 12 的入口。它模拟的是攻击者已经拿到容器内执行权例如通过 RCE之后的视角。3. flag 的来源:secretKeyRef 注入的环境变量。在 scenarios/system-monitor/deployment.yaml 中定义了 SecretapiVersion: v1 kind: Secret metadata: name: goatvault namespace: default type: Opaque data: k8sgoatvaultkey: azhzLWdvYXQtY2QyZGEyNzIyNDU5MWRhMmI0OGVmODM4MjZhOGE2YzMDeployment 通过valueFrom.secretKeyRef把它注入容器env: - name: K8S_GOAT_VAULT_KEY valueFrom: secretKeyRef: name: goatvault key: k8sgoatvaultkey见 deployment.yaml 第 47-52 行对清单中的 base64 值解码即可验证 flagecho azhzLWdvYXQtY2QyZGEyNzIyNDU5MWRhMmI0OGVmODM4MjZhOGE2YzM | base64 -d # 输出: k8s-goat-cd2da27224591da2b48ef83826a86c3这串k8s-goat-cd2da27224591da2b48ef83826a86c3就是本场景要你在容器内找到的 vault key 值。4. 顺带一提的额外风险面。从源码结构看同一个 system-monitor Pod 还声明了hostPID: true、hostIPC: true、privileged: true并把宿主机根目录hostPath: /挂载到/host-system见 deployment.yaml 第 25-46 行。这些配置服务于仓库中后续的容器逃逸相关场景在场景 12 里你不需要用到它们但这也提醒读者真实环境中一个既暴露了 Web Shell、又带有特权容器配置的 Pod风险是叠加的。如何把环境跑起来使用仓库根目录的 setup-kubernetes-goat.sh 部署所有场景清单其中 第 85 行 部署了scenarios/system-monitor/deployment.yaml再运行 access-kubernetes-goat.sh 建立本地端口转发然后浏览器访问http://127.0.0.1:1233即可进入 Web 终端访问http://127.0.0.1:1234则是集群内的 Kubernetes Goat 主页goat-home本场景的任务说明页由 infrastructure/goat-home/home/content/scenario-12.md 渲染。实战演练:容器内信息枚举Method 1进入 Web Shell 后场景指南给出的方法是把容器探索一遍。以下命令与 场景 12 指南 中的 Solution Walkthrough 一一对应。1. 确认自己是否在容器里:cat /proc/self/cgroupcat /proc/self/cgroup输出中的 cgroup 层级路径docker/containerd 风格的层级与容器 ID能直接暴露容器运行时信息帮助判断隔离边界。2. 查看容器主机的基础信息cat /etc/hosts/etc/hosts会显示 Pod 的容器 ID、主机名与网络配置是确认我正处在一个被编排过的环境里的常用手段。3. 查看挂载信息mountmount输出可以揭示容器看到了哪些文件系统挂载对于 system-monitor 这类把宿主机根目录挂进来的 Pod这里的信息量尤其大也印证了清单中的hostPath配置。4. 探索文件系统ls -la /home/逐步翻看目录结构了解容器内有哪些账号、文件与工具判断还有哪些入口点。5. 关键一击:printenv列出全部环境变量printenv这是场景 12 的核心命令。printenv会输出当前进程的全部环境变量其中就包含 Deployment 通过secretKeyRef注入的K8S_GOAT_VAULT_KEY——也就是那把 vault keyflag 值k8s-goat-cd2da27224591da2b48ef83826a86c3。除此之外Kubernetes 还会自动注入一批环境变量服务发现变量、KUBERNETES_SERVICE_HOST/KUBERNETES_SERVICE_PORT等 API Server 地址等这些同样是攻击者做横向移动的线索。拿到该值即完成场景。文档提示可以以多种方式找到它从仓库证据可以印证其中两种其一就是上面的容器内枚举其二是不进容器、直接从集群侧读取——kubectl get secret goatvault并对 base64 值解码结果与容器内看到的一致。这恰恰说明当凭据的读取权限容器内进程或集群 API 权限被突破后注入方式本身并不提供额外保护。为什么环境变量是弱防线:风险分析与加固建议场景 12 的价值在于演示了一条非常短的攻击链能执行任意命令 能读到全部环境变量 能拿到密钥。从本仓库的实现看其根因可以归纳为几点环境变量对容器内任何进程可见。主进程、它 fork 出的任何子进程、乃至通过/proc/1/environ这类内核接口都可以读到同一份环境变量。一个无密码的 gotty Web Shell 足以演示这一点——场景中甚至没有 RCE拿到 shell这一步被靶场直接送给了玩家。secretKeyRef 只保护清单里的值不保护运行时的值。使用secretKeyRef时kubectl get pod -o yaml不会显示密钥明文但任何已执行进容器的进程都能直接printenv拿到明文Pod 清单层面的隐藏因此形同虚设。凭据生命周期与注入方式错配。环境变量在容器创建时一次性注入、进程存活期间常驻内存无法按次读取、无法细粒度授权、也无法在进程间共享之外被其他进程看见。对应的加固方向与本场景的风险点逐条对应避免把长期有效的 API key 放进环境变量优先使用以文件形式挂载的 Secret Volume可控制文件权限或改用外部密钥管理系统按需注入。场景 12 指南的 References 即指向了 Kubernetes Secrets 概念与 Vault Agent 以 sidecar 方式注入密钥的模式——后者正是短时效、按需获取的典型代表。收紧能进入容器的一切入口无认证的 Web 终端、调试 sidecar、宽松的exec权限都会把环境变量直接暴露给攻击者RBAC 应按最小权限授予本仓库另有场景演示了服务账号被赋予过宽权限导致 Secret 可被 API 读取的情形可对照 scenarios/hunger-check/deployment.yaml 中的secret-readerRole 理解权限模型。消除叠加风险面本例 Pod 同时带有privileged: true与宿主机根目录挂载环境变量泄漏只是第一层损失对监控类负载应使用只读根文件系统、非特权容器与最小化命名空间挂载。关键文件索引内容仓库相对路径场景 12 指南Overview/Goal/Hints/Solution Walkthroughguide/docs/scenarios/scenario-12/scenario-12.md集群内置场景说明页1234 主页展示的任务文案infrastructure/goat-home/home/content/scenario-12.md场景清单Secret goatvault secretKeyRef 环境变量注入scenarios/system-monitor/deployment.yamlWeb Shell 镜像gotty -w bashEXPOSE 8080infrastructure/system-monitor/Dockerfile部署脚本第 85 行部署 system-monitorsetup-kubernetes-goat.sh端口转发脚本1233:8080 指向 system-monitor Podaccess-kubernetes-goat.sh适用前提说明以上所有步骤与端口映射以当前仓库的脚本与清单为准本地 1233 端口转发依赖access-kubernetes-goat.sh先于浏览访问运行flag 值取自当前清单中的 base64 数据。靶场环境仅应在隔离的实验集群中部署请勿将其中任何脆弱配置带入生产。【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 在 HIP 内核中稳定可用的编译器变更)
