企业官网建设流程全解析

Kubernetes Goat Scenario 17：用 KubeAudit 对 Kubernetes 集群做安全审计，把结果变成攻防行动清单

【免费下载链接】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 的 Scenario 17 展开，讲解如何在集群内部使用开源审计工具kubeaudit对集群资源做全量安全审计：如何利用具有集群管理员权限的tillerServiceAccount 启动hacker-container，理解kubeaudit all的检查项与集群工作模式，并基于审计输出决定是继续利用漏洞还是修复集群的误配置。读完本文，你可以独立完成一次针对 Kubernetes 集群的安全态势审计，并知道如何把审计结果转化为后续的利用或加固动作。

场景概览：为什么需要给集群做安全审计

本场景（Scenario 17: KubeAudit - Audit Kubernetes clusters）面向 Kubernetes 安全审计与评估任务。核心动作是在集群中运行开源工具kubeaudit，对它输出的安全误配置与漏洞清单进行解读，并据此决定下一步动作：

• 攻击者视角：把审计结果当作“漏洞地图”，挑选最薄弱的资源继续深入利用；
• 防御者视角：把审计结果当作整改清单，逐项修复集群中的安全问题。

文档原文指出，对于有审计与合规背景的人来说，在容器、Kubernetes 与云原生生态中掌握这类集群审计能力是必须的。完成本场景后，你将学到三件事：

1. 如何对 Kubernetes 集群执行安全审计；
2. 如何使用开源工具审计与调查集群资源；
3. 如何获得集群整体安全态势（security posture）的可见性，并理解其中的风险。

场景目标与提示

目标：执行一次 Kubernetes 安全审计，并拿到审计结果。

提示：不确定如何执行审计时，参考kubeaudit命令行工具本身的用法。kubeaudit是由 Shopify 开源的命令行工具（同时也是一个 Go 包），其官方文档与源码可在项目仓库中查阅，支持以不同模式对本地清单或整个集群进行审计。

前置条件：进入拥有集群管理员权限的审计容器

启动 hacker-container

审计工具要枚举集群里的所有资源，前提是它所使用的身份必须具备足够的 RBAC 权限。本场景要求你以tiller这个 ServiceAccount 的身份启动hacker-container（该账号已具备集群管理员权限）：

kubectl run -n kube-system --serviceaccount=tiller --rm --restart=Never -it --image=madhuakula/hacker-container -- bash

各参数含义如下：

执行后你会得到一个 bash shell，其中已注入集群访问凭据，后续所有审计命令都在这里执行。

权限从何而来：仓库中的 RBAC 配置

场景文档说明“tiller服务账号已经具有集群管理员权限”。这一点在仓库源码中有直接证据：

• infrastructure/helm-tiller/pwnchart/templates/clusterrole.yaml定义了一个名为all-your-base的 ClusterRole，其规则为apiGroups: ["*"]、resources: ["*"]、verbs: ["*"]，即对全部 API 组、全部资源、全部操作开放，等价于cluster-admin；
• infrastructure/helm-tiller/pwnchart/templates/clusterrolebinding.yaml通过名为belong-to-us的 ClusterRoleBinding 把该 ClusterRole 绑定到 ServiceAccount 上，绑定的命名空间与账号名由 chart 的values.yaml决定（默认值为namespace: default、name: default，部署时可通过 values 指定实际账号，例如tiller）；
• 另外，setup-kubernetes-goat.sh在部署 Goat 环境时还会应用scenarios/insecure-rbac/setup.yaml（脚本第 69 行），该文件在kube-system命名空间创建superadminServiceAccount 并将其绑定到内置的cluster-adminClusterRole：

# scenarios/insecure-rbac/setup.yaml apiVersion: v1 kind: ServiceAccount metadata: name: superadmin namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: superadmin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: superadmin namespace: kube-system

从源码结构看，Goat 环境是“Vulnerable by Design”：环境里刻意保留了多个过度提权的 ServiceAccount 与通配符 ClusterRole。这正是本场景能用一个 Pod 就审计到全集群资源的原因；同时，这些过度宽泛的 RBAC 绑定本身也是安全审计应当标记的一类高危配置。

实操走查：Method 1 —— 集群模式下运行 kubeaudit

kubeaudit 是什么

kubeaudit是一个命令行工具，用于审计 Kubernetes 集群中的各类安全问题，原文档列出的检查项包括：

• 是否以非 root 用户运行（run as non-root）；
• 是否使用只读根文件系统（read-only root filesystem）；
• 是否丢弃危险 capabilities、而不是新增 capabilities；
• 是否以 privileged 模式运行；
• 以及其他更多安全项。

执行集群模式审计

在hacker-container的 shell 中直接运行：

kubeaudit all

关键点在于集群模式：kubeaudit能够检测到自己正运行在集群内的一个容器里；一旦检测到，它会通过当前 ServiceAccount 的身份去审计该集群中的全部 Kubernetes 资源。由于tiller拥有集群管理员权限，kubeaudit all可以枚举并检查所有命名空间中的所有资源，输出一整份集群范围内的安全误配置清单（Pod、Deployment 等资源的名称、命名空间与对应问题项）。

运行效果可参考 Scenario 17 文档中的原始截图（本文开头配图即来源于 Scenario 17 文档）。

拿到审计结果之后

文档给出的下一步很直接：“根据你在 kubeaudit 中看到的漏洞，你可以继续推进进一步的利用（further exploitation）”。具体来说，结果可以从两个方向消费：

攻击路径：审计输出本质上是“哪些资源不符合安全基线”的清单。清单中privileged、以 root 运行、可写根文件系统、挂载了敏感卷等资源，通常也是容器逃逸、节点接管、凭据窃取等后续利用的首选目标。结合仓库中其他场景提供的攻击面（如特权容器、Secret 暴露等），可以按“风险最高、利用成本最低”的顺序逐个击破。

防御路径：对审计发现的每一类问题，回到工作负载的securityContext与 Pod 规约中修复，典型整改手段包括：

• 设置runAsNonRoot: true并指定非 root 用户/用户组；
• 设置readOnlyRootFilesystem: true，需要写入的路径用 emptyDir 等临时卷隔离；
• 在capabilities中显式drop危险 capabilities，避免add；
• 将privileged置为false，并收缩不必要的 hostPath、hostNetwork 挂载；
• 同时收敛本场景暴露出的 RBAC 问题：删除或收窄通配符 ClusterRole 与过度提权的 ServiceAccount。

仓库中 K8s OWASP Top 10 对照文档 可作为审计结果与行业风险分类之间的映射参考。

延伸说明与适用前提

• 本场景假定你已经通过setup-kubernetes-goat.sh部署了 Goat 环境（该脚本会部署insecure-rbac、batch-check、cache-store、metadata-db等一整套脆弱场景清单），并且集群中各 Pod 已处于 Running 状态；
• kubeaudit的集群模式依赖“工具自身运行在集群内”这一前提，并通过 Pod 内挂载的 ServiceAccount 令牌访问 API。如果换成集群外审计，则需通过 kubeconfig 与相应模式执行，检查对象与调用身份也会随之变化；
• 审计结果的覆盖面取决于执行身份可见的资源范围：身份权限越大，审计覆盖越全。本场景正是借助 Goat 环境刻意保留的集群管理员权限才实现了“全集群可见”，在真实环境中执行同类审计时，应使用专用只读审计账号并遵循最小权限原则。

参考资源（仓库内相对路径）

• Scenario 17 完整场景文档
• Scenario 17 导航页
• Goat 主页内嵌的 Scenario 17 说明
• 过度提权 RBAC 场景清单
• pwnchart 通配符 ClusterRole
• pwnchart ClusterRoleBinding
• pwnchart 默认 values
• 环境部署脚本
• K8s OWASP Top 10 文档

【免费下载链接】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