云容器与 Kubernetes 安全评估实战指南：基于 cloud-k8s 技能的四阶段审计工作流-迪斯科星球

云容器与 Kubernetes 安全评估实战指南：基于 cloud-k8s 技能的四阶段审计工作流

【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/gh_mirrors/an/agentic-awesome-skills

本篇指南以 Agentic Awesome Skills（AAS）仓库中的cloud-k8s技能为核心，系统讲解在授权范围内开展云工作负载与 Kubernetes 集群安全评估的完整方法论：从身份与边界确认、云控制面排查、容器逃逸路径评估，到集群 RBAC 审计的四个阶段，并提供可复制的命令行操作、工具链选型与任务自检清单。读完本文，你将掌握一套可立即用于授权渗透测试、云安全审计与红队演练的实战流程。

cloud-k8s是 AAS 技能库中一枚标记为risk: offensive的社区技能（source_type: community，源自 zhaoxuya520/reverse-skill，MIT 许可），其定位为「Authorized cloud, container, and Kubernetes security assessment」。它与同仓库的supply-chain-security、attack-chain、windows-ad、pentest-tools等技能互相联动，共同构成一套完整的攻防评估能力矩阵。

适用前提：授权边界与强制确认门禁

技能文件在正文开始前就给出了不可妥协的约束（见 SKILL.md 顶部）：

仅限授权使用：该技能仅用于教育目的或经授权的安全评估；使用前必须获得系统所有者的明确书面许可。
强制确认门禁（Mandatory confirmation gate）：在运行任何会对目标进行探测、利用、修改、持久化、数据提取或凭据访问的命令之前，必须依次完成四步：
1. 请用户明确说出目标 URL、IP、账号或资源；
2. 请用户确认书面授权及允许的范围；
3. 展示将执行的确切命令并说明预期效果；
4. 等待当前会话中的明确确认。
若未获确认，则保持只读，仅提供防御性建议；优先使用沙箱、一次性虚拟机或受控实验环境。

技能的路由上下文同样写明了红线：MUST NOT —— 未授权扫公有云其他租户。这意味着整个评估必须严格锁定在授权账号、集群与命名空间边界内。

技能定位与适用场景

技能的 When to Use 明确了两个核心触发场景：

在批准范围内评估云工作负载或 Kubernetes 集群安全；
审查 IAM/RBAC 配置中的权限提升路径。

对应到具体可执行的评估项（即cloud-k8s的适用场景清单）：

云元数据 SSRF（169.254.169.254/ IMDS）；
IAM 过度权限、公开存储桶、错误安全组；
Docker/containerd 逃逸路径评估；
Kubernetes RBAC、Secrets、Admission、供应链镜像；
容器镜像漏洞（可联动 supply-chain-security 技能）。

四阶段审计工作流

cloud-k8s将一次完整的云/K8s 安全评估拆解为四个阶段，每个阶段都包含「身份确认 + 命令执行 + 检查项核对」三要素。

Phase 1 — 身份与边界

评估的第一步不是跑工具，而是回答三个问题：

□ 当前身份：云 AK/SK、K8s SA、节点 SSH？ □ 范围：单账号 / 单 cluster / 单 namespace □ 网络档：authorized_target_only

当前身份决定了后续所有命令的合法性边界：持有云厂商 AccessKey/SecretKey 意味着你具备云控制面视角；持有 K8s ServiceAccount Token 意味着你具备集群内权限；而只有节点 SSH 则意味着评估将从主机层面展开。范围声明（单账号 / 单 cluster / 单 namespace）应在评估开始时以书面形式固定下来，并贯穿全程。网络档位设置为authorized_target_only，与技能路由上下文中的 MUST NOT 红线保持一致。

Phase 2 — 云控制面

在确认身份与范围后，进入云控制面排查。技能给出的命令示例按厂商替换，且 MUST 在授权账号内执行：

# 示例（按厂商替换；MUST 在授权账号内） aws sts get-caller-identity aws s3 ls # Azure / GCP 对应 identity 命令

aws sts get-caller-identity：确认当前调用者身份（Account、Arn、UserId），验证所用凭证是否属于授权账号；
aws s3 ls：列举可见存储桶，配合后续 ACL 检查识别公开桶与错误 ACL；
Azure 对应az account show、az ad signed-in-user show等身份确认命令；GCP 对应gcloud auth list、gcloud config list等。

完成身份确认后，按以下检查项逐一核对：

□ 公开桶 / 错误 ACL □ 元数据：IMDSv1 vs v2；SSRF 链 □ 角色可扮演（PassRole）与横向

元数据服务（IMDS）是本阶段的关键考点：云厂商元数据地址为169.254.169.254（link-local 地址，无法路由），攻击者通常借助 SSRF 漏洞访问该地址以窃取临时凭据。检查项要求区分 IMDSv1（无防护，任何能访问该地址的请求均可读取）与 IMDSv2（要求 PUT 请求获取 token 后再 GET 数据），并梳理从应用入口到元数据地址的 SSRF 利用链。PassRole 与横向则关注 IAM 角色信任关系中是否存在可被滥用的sts:AssumeRole路径，从而在同一账号或跨账号横向移动。

Phase 3 — 容器

第三阶段转向容器运行时安全，重点评估逃逸路径候选：

□ 是否 privileged / hostPath / hostNetwork □ capabilities（SYS_ADMIN 等） □ 可写宿主机路径 → 逃逸候选 □ 镜像历史与已知 CVE → Trivy

privileged：privileged: true的容器几乎拥有宿主机的全部内核能力，是最高危的逃逸起点；
hostPath：挂载宿主机目录（如/、/var/run/docker.sock）到容器，意味着容器内可读写宿主机文件系统；
hostNetwork：共享宿主机网络命名空间，可监听/嗅探宿主机网络流量；
capabilities：重点排查SYS_ADMIN、SYS_PTRACE、NET_ADMIN等危险 Linux capability，它们常被用于unshare、nsenter、cgroup逃逸等利用手法；
镜像历史与已知 CVE：使用 Trivy 对镜像进行漏洞扫描，并与后续供应链安全评估衔接。

Phase 4 — Kubernetes

第四阶段回到集群控制面，技能给出了三条核心命令：

kubectl auth can-i --list kubectl get pods,secrets,svc -A kubectl get clusterrolebindings

kubectl auth can-i --list：枚举当前身份在集群中「可以做」的所有动作，是 RBAC 权限面审计的第一手依据，可直接映射到技能 When to Use 中的「reviewing IAM/RBAC configurations for privilege-escalation paths」；
kubectl get pods,secrets,svc -A：跨命名空间枚举 Pod、Secret 与 Service，暴露敏感信息面与服务暴露面；
kubectl get clusterrolebindings：枚举集群级角色绑定，快速定位是否存在过度授予cluster-admin的情况。

随后按检查项核对：

□ SA token 挂载与权限 □ 危险 admission webhook 缺失 □ etcd / dashboard 暴露 □ 网络策略是否默认放行

SA token 挂载与权限：Kubernetes 1.20 前默认向 Pod 挂载 ServiceAccount Token，攻击者在被攻陷 Pod 内可直接读取该 token 调用 API Server，需评估其绑定的 RBAC 权限。Admission webhook 缺失意味着缺少准入控制层（如 OPA/Gatekeeper、Kyverno）对危险工作负载的拦截。etcd / dashboard 暴露则对应集群核心数据面（etcd 存储全部集群状态与 Secret）与控制台管理面被错误暴露的风险。网络策略默认放行对应默认的default-deny缺失——多数集群未配置 NetworkPolicy 时，Pod 间流量默认全放行，横向扩散成本极低。

工具链与自举策略

技能以表格形式给出了完整的工具链清单：

工具	用途	自举
kubectl	集群交互	手动
trivy	镜像/IaC	bootstrap`trivy`若可用
kube-bench / kubeaudit	CIS/配置	手动
pacu / scoutsuite	云审计（授权）	手动
nuclei	已知云漏洞模板	bootstrap nmap/nuclei 生态

kubectl：所有集群交互的基础工具，需手动安装并配置 kubeconfig；
Trivy：集镜像扫描、依赖扫描、IaC 配置扫描于一体，覆盖 Phase 3 的镜像 CVE 检查；
kube-bench：基于 CIS Kubernetes Benchmark 的自动化配置检查工具；kubeaudit：面向 Kubernetes 部署配置的审计工具，两者用于集群与工作负载的配置基线核查；
Pacu：AWS 云环境攻击框架，内置大量利用模块；ScoutSuite：多云安全审计工具，用于枚举 IAM、存储、网络等资源配置，均需在授权范围内使用；
nuclei：基于模板的漏洞扫描器，其云漏洞模板库可用于已知云漏洞模式探测，可通过 bootstrap 其生态（nmap/nuclei 相关模板）获得。

参考与关联技能导航

技能文件在「参考」一节中列出了三类可深挖的资料：

references/k8s-cloud-checklist.md：本技能的配套精简检查清单（详见下文）；
CTF 对照：指向../../CTF-Sandbox-Orchestrator/competition-agent-cloud/的竞赛场景对照（该路径为原文档相对路径，对应仓库中的云竞赛编排模块）；
姊妹技能：../supply-chain-security/与../pentest-tools/，即仓库中的 supply-chain-security 与 pentest-tools。

配套检查清单：k8s-cloud-checklist.md

技能的 references/k8s-cloud-checklist.md 将上述四个阶段浓缩为一张精简检查单，非常适合作为现场评估的对照表：

IMDS

SSRF 是否可达 169.254.169.254
是否强制 IMDSv2
返回的 IAM 角色权限面

K8s 高危

cluster-admin 绑定过多
secrets 明文环境变量
privileged + hostPID/hostPath 组合
匿名 auth / insecure apiserver 端口

容器

以 root 运行
可加载内核模块 / docker.sock 挂载

这份清单特别点出了几个容易遗漏的高危项：hostPID与privileged/hostPath组合（可读取宿主机进程、注入进程或直接操作宿主机文件）、匿名认证（--anonymous-auth=true）与不安全的 apiserver 端口、docker.sock挂载（等同于宿主机 root 权限）。

路由上下文：评估结果如何向下游衔接

cloud-k8s在技能库中处于承上启下的枢纽位置，其路由上下文定义了明确的上下游关系：

上游：MASTER R23（主编排流程的第 23 轮规则，决定何时调度本技能）；
下游：拿到节点 shell 后 → attack-chain / windows-ad；发现镜像漏洞 → 供应链安全链路；
MUST NOT：未授权扫公有云其他租户。

这种路由设计意味着：cloud-k8s负责「拿到立足点并评估纵深」，而attack-chain、windows-ad负责「立足点之后的内网/域渗透」，supply-chain-security负责「镜像与依赖漏洞的根治」。四者组合才能构成完整闭环。

任务完成自检

技能要求每次评估结束前必须通过以下自检：

是否限定在授权账号/cluster？
发现是否含复现与影响？
是否避免破坏性操作？
报告 / journal？

第一项复核授权边界是否始终未被突破；第二项要求每个发现都附带可复现的复现步骤与影响评估，而非一句「存在风险」；第三项强调评估全程避免破坏性操作（如删除资源、篡改数据）；第四项要求产出报告或日志记录，沉淀评估证据。

已知限制与合规提示

技能末尾明确列出了两条限制：

云厂商 API 调用可能产生费用并触发告警，需提前与资产所有者协调；
逃逸路径验证必须限定在一次性实验集群（disposable lab cluster）内进行。

这两条限制与开篇的授权门禁首尾呼应：云环境是共享的、可计费的、带告警的，任何探测都会留下痕迹并可能产生经济成本，因此沟通与授权是评估的前提而非可选步骤；而容器逃逸验证一旦落地即可能影响宿主机完整性，只能在一次性实验环境中完成。

在 AAS 体系中的定位

cloud-k8s的元数据（见 catalog.json 中cloud-k8s条目与 SKILL.md 的 frontmatter）表明：它以risk: offensive归类，源自社区仓库zhaoxuya520/reverse-skill（MIT 许可，2026-08-25 收录），并同时存在于plugins/agentic-awesome-skills-claude/skills/与plugins/agentic-awesome-skills/skills/两个插件目录中，供不同 Agent 运行时的技能路由使用。对于需要在授权项目中快速开展云/K8s 安全评估的工程师，直接按本文四阶段流程执行、配合检查清单核对、在路由上下文指导下衔接下游技能，即可获得一套开箱即用的评估方法论。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析