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 与云原生生态中掌握这类集群审计能力是必须的。完成本场景后你将学到三件事如何对 Kubernetes 集群执行安全审计如何使用开源工具审计与调查集群资源如何获得集群整体安全态势security posture的可见性并理解其中的风险。场景目标与提示目标执行一次 Kubernetes 安全审计并拿到审计结果。提示不确定如何执行审计时参考kubeaudit命令行工具本身的用法。kubeaudit是由 Shopify 开源的命令行工具同时也是一个 Go 包其官方文档与源码可在项目仓库中查阅支持以不同模式对本地清单或整个集群进行审计。前置条件进入拥有集群管理员权限的审计容器启动 hacker-container审计工具要枚举集群里的所有资源前提是它所使用的身份必须具备足够的 RBAC 权限。本场景要求你以tiller这个 ServiceAccount 的身份启动hacker-container该账号已具备集群管理员权限kubectl run -n kube-system --serviceaccounttiller --rm --restartNever -it --imagemadhuakula/hacker-container -- bash各参数含义如下参数作用-n kube-system在kube-system命名空间中创建 Pod--serviceaccounttiller容器内进程以tiller身份运行Kubernetes 会向该 Pod 挂载对应 ServiceAccount 的令牌供kubeaudit调用 API 时使用--rm会话结束后自动删除该资源避免遗留--restartNever容器为一次性运行失败不重启-it分配伪终端并附加标准输入方便交互式操作--imagemadhuakula/hacker-container使用内置了常用审计/渗透工具的容器镜像-- bash覆盖容器默认入口进入 bash shell执行后你会得到一个 bash shell其中已注入集群访问凭据后续所有审计命令都在这里执行。权限从何而来仓库中的 RBAC 配置场景文档说明“tiller服务账号已经具有集群管理员权限”。这一点在仓库源码中有直接证据infrastructure/helm-tiller/pwnchart/templates/clusterrole.yaml定义了一个名为all-your-base的 ClusterRole其规则为apiGroups: [*]、resources: [*]、verbs: [*]即对全部 API 组、全部资源、全部操作开放等价于cluster-admininfrastructure/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 —— 集群模式下运行 kubeauditkubeaudit 是什么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 通配符 ClusterRolepwnchart ClusterRoleBindingpwnchart 默认 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes Goat Scenario 17：用 KubeAudit 对 Kubernetes 集群做安全审计，把结果变成攻防行动清单
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 与云原生生态中掌握这类集群审计能力是必须的。完成本场景后你将学到三件事如何对 Kubernetes 集群执行安全审计如何使用开源工具审计与调查集群资源如何获得集群整体安全态势security posture的可见性并理解其中的风险。场景目标与提示目标执行一次 Kubernetes 安全审计并拿到审计结果。提示不确定如何执行审计时参考kubeaudit命令行工具本身的用法。kubeaudit是由 Shopify 开源的命令行工具同时也是一个 Go 包其官方文档与源码可在项目仓库中查阅支持以不同模式对本地清单或整个集群进行审计。前置条件进入拥有集群管理员权限的审计容器启动 hacker-container审计工具要枚举集群里的所有资源前提是它所使用的身份必须具备足够的 RBAC 权限。本场景要求你以tiller这个 ServiceAccount 的身份启动hacker-container该账号已具备集群管理员权限kubectl run -n kube-system --serviceaccounttiller --rm --restartNever -it --imagemadhuakula/hacker-container -- bash各参数含义如下参数作用-n kube-system在kube-system命名空间中创建 Pod--serviceaccounttiller容器内进程以tiller身份运行Kubernetes 会向该 Pod 挂载对应 ServiceAccount 的令牌供kubeaudit调用 API 时使用--rm会话结束后自动删除该资源避免遗留--restartNever容器为一次性运行失败不重启-it分配伪终端并附加标准输入方便交互式操作--imagemadhuakula/hacker-container使用内置了常用审计/渗透工具的容器镜像-- bash覆盖容器默认入口进入 bash shell执行后你会得到一个 bash shell其中已注入集群访问凭据后续所有审计命令都在这里执行。权限从何而来仓库中的 RBAC 配置场景文档说明“tiller服务账号已经具有集群管理员权限”。这一点在仓库源码中有直接证据infrastructure/helm-tiller/pwnchart/templates/clusterrole.yaml定义了一个名为all-your-base的 ClusterRole其规则为apiGroups: [*]、resources: [*]、verbs: [*]即对全部 API 组、全部资源、全部操作开放等价于cluster-admininfrastructure/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 —— 集群模式下运行 kubeauditkubeaudit 是什么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 通配符 ClusterRolepwnchart ClusterRoleBindingpwnchart 默认 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考