云容器与 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 SkillsAAS仓库中的cloud-k8s技能为核心系统讲解在授权范围内开展云工作负载与 Kubernetes 集群安全评估的完整方法论从身份与边界确认、云控制面排查、容器逃逸路径评估到集群 RBAC 审计的四个阶段并提供可复制的命令行操作、工具链选型与任务自检清单。读完本文你将掌握一套可立即用于授权渗透测试、云安全审计与红队演练的实战流程。cloud-k8s是 AAS 技能库中一枚标记为risk: offensive的社区技能source_type: community源自 zhaoxuya520/reverse-skillMIT 许可其定位为「Authorized cloud, container, and Kubernetes security assessment」。它与同仓库的supply-chain-security、attack-chain、windows-ad、pentest-tools等技能互相联动共同构成一套完整的攻防评估能力矩阵。适用前提授权边界与强制确认门禁技能文件在正文开始前就给出了不可妥协的约束见 SKILL.md 顶部仅限授权使用该技能仅用于教育目的或经授权的安全评估使用前必须获得系统所有者的明确书面许可。强制确认门禁Mandatory confirmation gate在运行任何会对目标进行探测、利用、修改、持久化、数据提取或凭据访问的命令之前必须依次完成四步请用户明确说出目标 URL、IP、账号或资源请用户确认书面授权及允许的范围展示将执行的确切命令并说明预期效果等待当前会话中的明确确认。若未获确认则保持只读仅提供防御性建议优先使用沙箱、一次性虚拟机或受控实验环境。技能的路由上下文同样写明了红线MUST NOT —— 未授权扫公有云其他租户。这意味着整个评估必须严格锁定在授权账号、集群与命名空间边界内。技能定位与适用场景技能的 When to Use 明确了两个核心触发场景在批准范围内评估云工作负载或 Kubernetes 集群安全审查 IAM/RBAC 配置中的权限提升路径。对应到具体可执行的评估项即cloud-k8s的适用场景清单云元数据 SSRF169.254.169.254/ IMDSIAM 过度权限、公开存储桶、错误安全组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 检查识别公开桶与错误 ACLAzure 对应az account show、az ad signed-in-user show等身份确认命令GCP 对应gcloud auth list、gcloud config list等。完成身份确认后按以下检查项逐一核对□ 公开桶 / 错误 ACL □ 元数据IMDSv1 vs v2SSRF 链 □ 角色可扮演PassRole与横向元数据服务IMDS是本阶段的关键考点云厂商元数据地址为169.254.169.254link-local 地址无法路由攻击者通常借助 SSRF 漏洞访问该地址以窃取临时凭据。检查项要求区分 IMDSv1无防护任何能访问该地址的请求均可读取与 IMDSv2要求 PUT 请求获取 token 后再 GET 数据并梳理从应用入口到元数据地址的 SSRF 利用链。PassRole 与横向则关注 IAM 角色信任关系中是否存在可被滥用的sts:AssumeRole路径从而在同一账号或跨账号横向移动。Phase 3 — 容器第三阶段转向容器运行时安全重点评估逃逸路径候选□ 是否 privileged / hostPath / hostNetwork □ capabilitiesSYS_ADMIN 等 □ 可写宿主机路径 → 逃逸候选 □ 镜像历史与已知 CVE → Trivyprivilegedprivileged: 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 clusterrolebindingskubectl 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镜像/IaCbootstraptrivy若可用kube-bench / kubeauditCIS/配置手动pacu / scoutsuite云审计授权手动nuclei已知云漏洞模板bootstrap nmap/nuclei 生态kubectl所有集群交互的基础工具需手动安装并配置 kubeconfigTrivy集镜像扫描、依赖扫描、IaC 配置扫描于一体覆盖 Phase 3 的镜像 CVE 检查kube-bench基于 CIS Kubernetes Benchmark 的自动化配置检查工具kubeaudit面向 Kubernetes 部署配置的审计工具两者用于集群与工作负载的配置基线核查PacuAWS 云环境攻击框架内置大量利用模块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 将上述四个阶段浓缩为一张精简检查单非常适合作为现场评估的对照表IMDSSSRF 是否可达 169.254.169.254是否强制 IMDSv2返回的 IAM 角色权限面K8s 高危cluster-admin 绑定过多secrets 明文环境变量privileged hostPID/hostPath 组合匿名 auth / insecure apiserver 端口容器以 root 运行可加载内核模块 / docker.sock 挂载这份清单特别点出了几个容易遗漏的高危项hostPID与privileged/hostPath组合可读取宿主机进程、注入进程或直接操作宿主机文件、匿名认证--anonymous-authtrue与不安全的 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-skillMIT 许可2026-08-25 收录并同时存在于plugins/agentic-awesome-skills-claude/skills/与plugins/agentic-awesome-skills/skills/两个插件目录中供不同 Agent 运行时的技能路由使用。对于需要在授权项目中快速开展云/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 云容器与 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 SkillsAAS仓库中的cloud-k8s技能为核心系统讲解在授权范围内开展云工作负载与 Kubernetes 集群安全评估的完整方法论从身份与边界确认、云控制面排查、容器逃逸路径评估到集群 RBAC 审计的四个阶段并提供可复制的命令行操作、工具链选型与任务自检清单。读完本文你将掌握一套可立即用于授权渗透测试、云安全审计与红队演练的实战流程。cloud-k8s是 AAS 技能库中一枚标记为risk: offensive的社区技能source_type: community源自 zhaoxuya520/reverse-skillMIT 许可其定位为「Authorized cloud, container, and Kubernetes security assessment」。它与同仓库的supply-chain-security、attack-chain、windows-ad、pentest-tools等技能互相联动共同构成一套完整的攻防评估能力矩阵。适用前提授权边界与强制确认门禁技能文件在正文开始前就给出了不可妥协的约束见 SKILL.md 顶部仅限授权使用该技能仅用于教育目的或经授权的安全评估使用前必须获得系统所有者的明确书面许可。强制确认门禁Mandatory confirmation gate在运行任何会对目标进行探测、利用、修改、持久化、数据提取或凭据访问的命令之前必须依次完成四步请用户明确说出目标 URL、IP、账号或资源请用户确认书面授权及允许的范围展示将执行的确切命令并说明预期效果等待当前会话中的明确确认。若未获确认则保持只读仅提供防御性建议优先使用沙箱、一次性虚拟机或受控实验环境。技能的路由上下文同样写明了红线MUST NOT —— 未授权扫公有云其他租户。这意味着整个评估必须严格锁定在授权账号、集群与命名空间边界内。技能定位与适用场景技能的 When to Use 明确了两个核心触发场景在批准范围内评估云工作负载或 Kubernetes 集群安全审查 IAM/RBAC 配置中的权限提升路径。对应到具体可执行的评估项即cloud-k8s的适用场景清单云元数据 SSRF169.254.169.254/ IMDSIAM 过度权限、公开存储桶、错误安全组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 检查识别公开桶与错误 ACLAzure 对应az account show、az ad signed-in-user show等身份确认命令GCP 对应gcloud auth list、gcloud config list等。完成身份确认后按以下检查项逐一核对□ 公开桶 / 错误 ACL □ 元数据IMDSv1 vs v2SSRF 链 □ 角色可扮演PassRole与横向元数据服务IMDS是本阶段的关键考点云厂商元数据地址为169.254.169.254link-local 地址无法路由攻击者通常借助 SSRF 漏洞访问该地址以窃取临时凭据。检查项要求区分 IMDSv1无防护任何能访问该地址的请求均可读取与 IMDSv2要求 PUT 请求获取 token 后再 GET 数据并梳理从应用入口到元数据地址的 SSRF 利用链。PassRole 与横向则关注 IAM 角色信任关系中是否存在可被滥用的sts:AssumeRole路径从而在同一账号或跨账号横向移动。Phase 3 — 容器第三阶段转向容器运行时安全重点评估逃逸路径候选□ 是否 privileged / hostPath / hostNetwork □ capabilitiesSYS_ADMIN 等 □ 可写宿主机路径 → 逃逸候选 □ 镜像历史与已知 CVE → Trivyprivilegedprivileged: 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 clusterrolebindingskubectl 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镜像/IaCbootstraptrivy若可用kube-bench / kubeauditCIS/配置手动pacu / scoutsuite云审计授权手动nuclei已知云漏洞模板bootstrap nmap/nuclei 生态kubectl所有集群交互的基础工具需手动安装并配置 kubeconfigTrivy集镜像扫描、依赖扫描、IaC 配置扫描于一体覆盖 Phase 3 的镜像 CVE 检查kube-bench基于 CIS Kubernetes Benchmark 的自动化配置检查工具kubeaudit面向 Kubernetes 部署配置的审计工具两者用于集群与工作负载的配置基线核查PacuAWS 云环境攻击框架内置大量利用模块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 将上述四个阶段浓缩为一张精简检查单非常适合作为现场评估的对照表IMDSSSRF 是否可达 169.254.169.254是否强制 IMDSv2返回的 IAM 角色权限面K8s 高危cluster-admin 绑定过多secrets 明文环境变量privileged hostPID/hostPath 组合匿名 auth / insecure apiserver 端口容器以 root 运行可加载内核模块 / docker.sock 挂载这份清单特别点出了几个容易遗漏的高危项hostPID与privileged/hostPath组合可读取宿主机进程、注入进程或直接操作宿主机文件、匿名认证--anonymous-authtrue与不安全的 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-skillMIT 许可2026-08-25 收录并同时存在于plugins/agentic-awesome-skills-claude/skills/与plugins/agentic-awesome-skills/skills/两个插件目录中供不同 Agent 运行时的技能路由使用。对于需要在授权项目中快速开展云/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考