云与部署安全审计实战指南：用 security-audit Skill 猎捕 IAM、容器与配置漂移类漏洞-平芜编程栈

AI 技能
应用安全

【免费下载链接】security-audit-skill

A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings

项目地址：https://gitcode.com/GitHub_Trending/se/security-audit-skill

云部署代码（IAM 策略、基础设施即代码、容器与 Kubernetes 清单、Service Mesh、Serverless/Edge 函数、Ingress、对象存储、托管服务与环境配置）是安全审计中事实密度最高、也最容易产生误报的领域。本指南以开源仓库 security-audit 的 CLOUD-AND-DEPLOYMENT.md 为骨架，系统讲解该编码代理技能在云与部署域的五类攻击模型（Workload 身份与 IAM、Ingress 与网络控制面、容器与编排、配置与机密生命周期、托管存储/事件/边缘）、贯穿所有场景的通用动作，以及上报任何结论前必须满足的五条验证规则。读完本文，你将掌握如何在审计中区分"源码可证实的缺陷"与"需要所有者观测的部署事实"，并能为被审计仓库产出confirmed与needs_validation两类有据可查的发现记录。

该文档的使用时机与触发场景

security-audit 是一个多阶段、源码优先的安全审计技能，其完整工作流（侦察、覆盖度驱动猎捕、候选验证、结构化输出、独立记录复核、目标中立报告）定义在 SKILL.md 中。云与部署是它按攻击面拆分的多个领域文档之一，ATTACK-CLASSES.md 在按目标类型选择攻击类别的说明中明确：当目标涉及IAM、基础设施即代码、容器/Kubernetes、Service Mesh、Serverless/边缘、Ingress、Provider 事件或运行时配置时，应选用 CLOUD-AND-DEPLOYMENT.md。

具体而言，当被审计仓库中出现以下任一要素时，猎手代理（subagent）就应打开该文档：

云身份与基础设施：云身份（cloud identity）、基础设施、容器、Kubernetes、Service Mesh、Serverless 函数、边缘 Worker、Ingress、对象存储、托管服务、环境特定配置；
需要回答的核心问题：已部署的组件是否获得了预期的身份（identity）、隔离（isolation）、网络可达性（network reachability）、机密（secrets）与策略（policy）。

该文档还划清了与其他领域文档的边界，避免重复审计：

相邻领域	对应文档	分工
构建与发布信任（依赖、CI、签名、升级、插件）	SUPPLY-CHAIN-AND-RELEASE.md	构建产物从源码到用户运行的信任交接
HTTP 代理语义（转发头、缓存、认证协议）	WEB-PROTOCOL-AND-AUTH.md	HTTP 请求构框、缓存与认证协议
数据存储的租户范围（多租户隔离、缓存、导出/迁移/删除）	DATA-ISOLATION-AND-LIFECYCLE.md	数据存储层的租户作用域

一个关键背景是：源码通常表达"意图"而非"事实"。云部署的真实生效策略往往取决于哪个环境消费该清单、哪些默认值或 overlay 覆盖了它、以及该源码路径是否真正处于激活状态。因此审计者必须把"源码可确认的缺陷"与"需要部署验证的事实"严格分开，这正是该文档所有攻击类别与验证规则围绕的轴心。

核心纪律：注入每个云域代理提示词的五条铁律

CLOUD-AND-DEPLOYMENT.md 要求，凡是覆盖本域的猎手提示词，都必须原样包含以下核心纪律块（在 HUNTING.md 的猎手提示词结构中，这是"选定伴生块"的一部分，与攻击类别小节、通用动作、验证规则一起逐字复制给代理）：

- Do not infer a live exposure from a manifest alone. Establish which environment consumes it, what defaults or overlays modify it, and whether the source path is active. - Map each workload's identity to specific operations and resources. Broad policy is a finding only when lower-trust input can reach an unauthorized action. - Ingress, proxies, service mesh, metadata services, and admission policy are real boundaries, but only count a control when its configuration and attachment are visible. - Secret references are not secret disclosure. Require a lower-trust reader, output, artifact, log path, or unsafe fallback. - Use `confirmed` for active in-repo configurations and local rendering/policy validation. Use `needs_validation` for account policy, network attachment, runtime admission, hosted metadata, or drift that needs owner observation.

逐条拆解其工程含义：

不要仅凭清单推断真实暴露。一份 Kubernetes 清单或 Terraform 文件存在于仓库中，不代表它就是线上生效的那份。审计者必须确定：哪个环境消费它、默认值与 overlay（如 Helm values、Kustomize 补丁、按 region 的环境变量）如何修改它、该源码路径当前是否激活。这直接对应 SKILL.md 的"Respect source visibility"原则——部署控制、Provider 设置、拓扑等若不在仓库内，既不能假设其存在，也不能假设其缺失。
把每个 Workload 的身份映射到具体操作与资源。宽泛的"策略过宽"只有在低信任输入能够触达一个未授权动作时才构成发现。例如一个 ServiceAccount 拥有过大的 Role 权限本身只是配置建议，必须证明某个可由低信任请求或任务输入选择的目标（tenant、account、resource、API）会被该身份越权操作，才算漏洞。
Ingress、代理、Service Mesh、元数据服务、准入策略是真实边界，但只有"配置 + 挂载（attachment）"均可见时才计为一个控制。安全审计只认可见的控制。若仓库里写了一段网络策略但没有任何对象挂载它，或 mesh 注入配置存在但无法确认 Sidecar 是否真正注入，则该控制对审计结论的支撑是有限的。
机密引用 ≠ 机密泄露。代码里出现os.Getenv("DB_PASSWORD")或引用 Secret 卷不是漏洞。要构成泄露，必须存在一个更低信任的读者、输出、制品、日志路径或非安全回退能实际拿到凭据值。这条与 SKILL.md 中"禁止把防御纵深缺失升格为漏洞"的基调一致——公开端点或 Key ID 不是凭据。
严格区分两个结论等级：
- confirmed：仓库内激活的配置 + 本地渲染/策略验证可确立完整边界与具体结果；
- needs_validation：账户策略、网络挂载、运行时准入、托管元数据或漂移（drift）需要所有者观测，且该事实对结论是决定性的。

这两类记录在 report-schema.json 中结构截然不同：confirmed需要root_cause、execution.observed_result、remediation、severity等字段，且总体严重度不得超过已证实的 impact；needs_validation则必须携带blockers和至少一个validation_plan.local或validation_plan.deployment计划，且禁止包含 severity（该约束由 validate-findings.cjs 在 Phase 4/5 强制检查）。

攻击类别一：Workload 身份与 IAM

本类别由general子代理执行，覆盖三种攻击模型：

Workload 身份越权（Workload identity overreach）

一个 Workload、Pod、函数、边缘 Worker 或节点身份，可以作用在其角色范围之外的租户、账户、资源或 API 之上，并且不可信请求或任务输入可以选择该目标。审查要点：

云策略条件（policy conditions）；
资源模式（resource patterns，即策略中对资源 ARN/名称的通配或前缀限定）；
ServiceAccount 挂载（attachment）；
命名空间映射（namespace mapping）；
回退凭据（fallback credentials，如从实例元数据意外取到的角色）。

典型形态：某函数对特定前缀的对象拥有写权限，但函数名或对象 Key 由调用方输入决定，导致低信任输入能把写操作引导到策略条件之外的资源。

跨账户/跨租户角色混淆（Cross-account or cross-tenant role confusion）

角色扮演（role assumption）、External ID、令牌交换（token exchange）、Workload 联合（workload federation）或资源策略接受了未绑定到预期源账户、受众（audience）、仓库、命名空间或 Workload 的身份声明。审计时必须同时建立两件事：

信任策略（trust policy）：谁被允许扮演该角色；
调用方可控声明（caller-controlled claim）：调用方能在扮演请求中放入哪些字段。

若调用方可以自由选择RoleArn、ExternalId、aud或命名空间标签，而信任策略没有用这些字段做强绑定，则可能把某账户的高权角色扮演给低信任主体。

应用授权被委托给云元数据（Application authorization delegated to cloud metadata）

应用信任调用方提供的身份头、标签、注解、账户 ID 或资源元数据，却没有验证它们来自云控制面或可信代理。核心区分：云 IAM 与应用授权是两个独立的检查。例如后端依据X-Forwarded-For、X-Amz-Cognito-Identity-Id或对象标签决定授权，但该值可由调用方直接构造，那么仓库中的这段应用授权代码就是一个真实边界漏洞——除非有可信代理剥离并重写这些头。

攻击类别二：Ingress、网络与控制面

意外暴露的服务或管理面可达性（Unexpected service or management-plane reachability）

Ingress、Service、监听器、安全组、负载均衡注解、端口映射或服务器绑定，把管理接口、调试接口、指标、节点、控制面或内部 API暴露给了更低信任的网络。判定要点：

缺少网络控制本身只算needs_validation——因为仓库内看不到真实安全组挂载与流量路径；
仓库可控的、通往敏感处理器的公网路由可以算confirmed——例如 Terraform 里显式声明了一个向0.0.0.0/0开放的 Load Balancer 监听器并指向管理端口。

可信代理与 Mesh 身份绕过（Trusted-proxy and mesh identity bypass）

后端接受了来自预期 Ingress/Sidecar 之外对等方的转发身份、mTLS 主体或授权元数据，或者备用端口、健康检查路径、遗留路径绕过了 Mesh。审计时需验证：

头部剥离（header stripping）：反向代理是否清除了调用方可控的身份头；
对等方可达性（peer reachability）：其他网络路径是否直达后端；
代理缺失时的 fail-open 行为：当 proxy/sidecar 不存在或注入失败时，后端是否仍然放行。

元数据与内部服务可达性（Metadata and internal-service reachability）

不可信的 URL、目标或协议选择，可以触达实例/容器元数据、控制面 Socket 或携带 Workload 凭据的内部 API（经典的 IMDS SSRF 即属此类）。该文档要求在此建立"部署后的网络、元数据版本与身份边界"，而 URL 解析与重定向处理本身的漏洞细节，应回溯到 ATTACK-CLASSES.md 中 Resource and file handling 的 SSRF 条目——两个文档分工协作：这里确认部署层面的可达边界，那里追踪解析器差异与重定向链。

攻击类别三：容器与编排

主机或控制面能力暴露（Host or control-plane capability exposure）

低信任 Workload 可以选中特权模式、capabilities、主机命名空间、主机路径、设备挂载、容器运行时 Socket 或 ServiceAccount 令牌，从而越入节点/控制面权威。文档特别强调一条反误报准则：

仅仅缺少 seccomp 或只读文件系统属于加固建议（hardening），除非存在一条可达的操作真正跨越该边界。

也就是说，privileged: true单独出现不是漏洞；必须证明一个低信任输入能驱动该容器执行越权动作。这与 SKILL.md 的"防御纵深缺口不是漏洞"原则完全一致。

准入与策略路径不一致（Admission and policy path inconsistency）

一条部署路径强制了镜像身份、命名空间、资源、机密或权限策略，而另一条控制器、Job、升级、恢复或兼容路径没有。审计者必须确认那条备用路径以及它最终产生的已部署对象（resulting deployed object）——例如一个 Operator 通过自定义控制器绕过 ValidatingWebhook 直接创建 Pod。

命名空间与标签信任混淆（Namespace and label trust confusion）

网络、准入、机密或 Workload 身份策略依赖低信任主体可以设置的标签、注解、名称或命名空间。审计动作：比较"谁能设置选择器（selector）"与"匹配成功授予什么权威"。如果 NetworkPolicy 按app=trusted标签放行，而该标签可由普通用户通过任意 Deployment 的 metadata 写入，则策略的信任根是脆弱的。

攻击类别四：配置与机密生命周期

安全控制优先级漂移（Security-control precedence drift）

开发环境值、Chart 默认值、环境变量、命令行 Flag、Feature Gate、Sidecar 注入开关或按 region 的 overlay，可能在已部署环境中禁用了认证、传输安全、租户作用域或审计策略。文档给出的纪律是：

为每一个受维护的部署渲染最终配置（render the final configuration），而不是只看基础文件。

这正是核心纪律第 5 条在实操中的落地：本地用 Helm/Kustomize 渲染出各环境的最终 YAML，再逐项核对传输安全、认证与租户隔离是否被 overlay 覆盖。这类"仓库内激活配置 + 本地渲染验证"的结果可以安全地给出confirmed。

跨 Workload 边界的机密暴露（Secret exposure across workload boundaries）

机密进入日志、崩溃报告、进程参数、共享环境、过宽卷、构建输出、服务发现或另一个 Workload/租户可读的 API。审计要点：

检查机密类型与权威（secret type and authority）；
公开端点或 Key ID 不是凭据——例如某个公网对象存储中只有配置文档没有私钥值，不算泄露。

凭据续期与故障回退（Credential renewal and outage fallback）

未能挂载、刷新、轮换或撤销 Workload 凭据，会导致过期凭据仍然活跃，或应用接受更低信任的身份模式。审查启动（startup）、就绪（readiness）、重连（reconnect）与缓存客户端（cached-client）行为——例如凭据缓存命中永不过期，或 AWS SDK 在 IMDS 失败时静默回退到环境变量中的长期密钥。

攻击类别五：托管存储、事件与边缘

对象与签名 URL 策略混淆（Object and signed-URL policy confusion）

Bucket/容器策略、对象 Key、CDN 源或签名 URL未能绑定主体、操作、对象命名空间、受众或过期时间。审查必须覆盖列（list）/版本（version）操作与写路径，而不仅是读路径——经典的"桶可公开列目录"或"预签名 URL 无前缀限制导致越权下载"即属此类。

事件源身份混淆（Event-source identity confusion）

函数或 Worker 把事件体字段当作源身份，却没有验证 Provider 签名的信封、订阅/主题、账户、区域与重放状态。必须对比**推（push）、拉（pull）、重试（retry）与死信（dead-letter）**四条路径——因为重试路径往往绕过在推送路径上校验的订阅身份绑定。

边缘/运行时边界不匹配（Edge/runtime boundary mismatch）

边缘或 Serverless 运行时假设了与源运行时不同的机密、API、文件系统、隔离或租户策略，而回退到源站（origin）会改变权威或缓存行为。审计动作：确认哪条配置选择了哪条路径（例如 Worker 代码中env.ORIGIN决定回源地址，而边缘环境变量由外部系统注入）。

贯穿所有类别的通用动作（Universal moves）

在任意一个或多个攻击类别下，CLOUD-AND-DEPLOYMENT.md 还要求三条贯穿动作，它们与 RECONNAISSANCE.md 中"本地执行与部署可见性"的侦察代理任务直接呼应：

渲染每个受维护的环境，制作矩阵：以外部端口、Workload 身份、网络对等方、挂载的机密、云资源为列，逐一填写每个环境的取值。任何差异都需要所有者或策略给出解释——差异本身是漂移的候选证据。
把低信任请求、对象、标签或事件一路跟进到云策略：展示哪个 Workload 凭据执行了最终操作、什么条件本应限定该操作。这是把"策略过宽"从配置建议升级为漏洞的唯一路径——最终动作的执行者与限定条件必须具体到可以引用源码行。
对比正常部署、迁移、恢复、节点维护、故障转移与本地/模拟器路径，并审查当 Mesh、准入、身份、机密或策略服务不可用时系统的行为——降级路径的默认行为（fail-open 与否）本身就是安全事实。

上报任何云域发现前的五条验证规则

这是该文档的收尾部分，也是强制的"候选门禁"（candidate gate），适用于本域任何一条上报：

建立激活的源码路径与生效的部署对象；否则使用needs_validation，并说明缺的是哪份渲染后的清单或哪个需所有者观测的挂载。
具名四要素：低信任调用方/Workload、云或应用身份、可控的选择器（controllable selector）、受影响资源与未授权操作或泄露。要素不全就不成其为可验证的发现。
核对钉死版本下的 Provider 与编排器默认值。不要假设存在公网 IP、可达的元数据服务、宽松防火墙或缺失的准入挂载——默认行为必须依据被审计仓库钉死的版本查证。
本地验证保持有界：可以渲染模板、评估策略、在隔离夹具（isolated fixture）中检查容器/用户命名空间，或用虚拟身份运行模拟器（emulator）。严禁探测在线端点或改动共享云资源——这与 SKILL.md 的沙箱执行边界（无外网、空环境白名单、只读目标、scratch 专属写入）严格一致。
结论分级：confirmed必须包含完整的激活源码追踪与具体的边界结果；needs_validation必须给出确切缺失的部署策略、身份挂载、overlay、网络或漂移观测项。该分级随后会被 Phase 3 的新鲜验证者（fresh verifier）复核，并由 report-schema.json 与 validate-findings.cjs 做结构性强制——例如confirmed记录不得携带blockers/validation_plan，needs_validation记录不得携带severity。

在完整审计流程中的位置

云与部署域文档不是孤立清单，而是嵌入 security-audit 六阶段流水线的一个"伴生块"（companion）：

Phase 1 侦察：Agent 1d（本地执行与部署可见性）会识别"部署控件与挂载中源码无法建立、若决定性则需needs_validation的部分"，并在 RECONNAISSANCE.md 定义的architecture.md中完成伴生块选择——只有当侦察发现文档When to use this file所描述的信任敏感边界时，才选择本文件；
Phase 2 猎捕：每个覆盖本域的 ledger 单元会逐字携带本文件的Core discipline、所选攻击类别小节、Universal moves与Validation rules（见 HUNTING.md 的猎手提示词结构），猎手以结构化 JSON 返回 covered/candidate/blocked 结果；
Phase 3/5 验证：候选提交给从未参与猎捕的新鲜验证者，验证者独立复核源码行与有界结果，可把needs_validation升为confirmed（仅当独立确立完整路径与结果）或把confirmed降级；
Phase 4/6 输出：记录按三个 verdict 分支写入findings.json并经无依赖校验器验证，最终生成目标中立的 [REPORT.md / FINDINGS-DETAIL.md / NEEDS-VALIDATION.md]。