Back to Details

competition-cloud-metadata-path

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Competition Cloud Metadata Path

竞赛云元数据路径

Use this skill only as a downstream specialization after 
$ctf-sandbox-orchestrator
is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to 
$ctf-sandbox-orchestrator
first.
Use this skill when the decisive edge is not just reaching metadata, but proving how metadata-derived identity becomes accepted privilege.
Reply in Simplified Chinese unless the user explicitly requests English.
本技能仅可在
$ctf-sandbox-orchestrator
已处于激活状态，且已经完成沙箱假设建立、节点所有权确认和证据优先级划分后，作为下游专属技能使用。如果还未完成上述步骤，请先返回
$ctf-sandbox-orchestrator
流程。
当核心突破点不止是访问到元数据，而是需要证明从元数据获取的身份如何转换为可被认可的权限时，请使用本技能。
除非用户明确要求英文回复，否则请使用简体中文回复。

Quick Start

快速开始

  1. Identify which metadata surface is active: instance metadata, workload identity, node identity, task role, or platform-specific token endpoint.
  2. Record the exact reachability path: local process, pod, container, proxy, SSRF surface, or host route.
  3. Separate metadata reachability from credential issuance and from downstream privilege acceptance.
  4. Keep token format, role identity, scope, and accepting API in compact evidence blocks.
  5. Reproduce the smallest metadata-to-accepted-privilege path that proves the challenge edge.
  1. 确定当前激活的元数据接口类型：实例元数据、工作负载身份、节点身份、任务角色或平台专属令牌端点。
  2. 记录准确的可达路径：本地进程、Pod、容器、代理、SSRF接口或主机路由。
  3. 将元数据可达性、凭证发放、下游权限接受三个环节区分开。
  4. 将令牌格式、角色身份、作用域、可接受的API整理到精简的证据块中。
  5. 复现能够证明挑战边界的最短元数据到权限被认可路径。

Workflow

工作流

1. Map Metadata Reachability

1. 梳理元数据可达性

  • Record the metadata endpoint, required headers, hop limits, session tokens, workload selectors, or path prefixes.
  • Note whether access comes from direct local calls, pod networking, SSRF, sidecar, or host-level routing.
  • Keep the reaching surface and the metadata endpoint in one chain.
  • 记录元数据端点、必填请求头、跳数限制、会话令牌、工作负载选择器或路径前缀。
  • 标记访问来自直接本地调用、Pod网络、SSRF、边车容器还是主机层级路由。
  • 将访问入口和元数据端点整理为完整链路。

2. Prove Credential Or Identity Issuance

2. 证明凭证或身份发放

  • Show how the metadata response becomes a token, temporary credential, signed identity doc, or platform-specific workload identity.
  • Record expiration, role name, subject, audience, issuer, or cloud account mapping that matters downstream.
  • Distinguish raw metadata from usable credential material.
  • 展示元数据响应如何转换为令牌、临时凭证、签名身份文档或平台专属工作负载身份。
  • 记录对下游链路有影响的过期时间、角色名称、主体、受众、签发者或云账户映射关系。
  • 区分原始元数据和可使用的凭证材料。

3. Reduce To The Decisive Trust Path

3. 简化为决定性信任路径

  • Compress the result to the smallest sequence: reaching surface -> metadata call -> credential issued -> accepted cloud or cluster action.
  • State clearly whether the weakness lives in reachability, metadata config, role trust, downstream policy, or workload binding.
  • If the challenge narrows to RBAC or cluster mutation after credential issuance, switch back to the tighter control-plane skill.
  • 将结果压缩为最短链路：访问入口 -> 元数据调用 -> 凭证发放 -> 云或集群操作被接受。
  • 明确说明漏洞存在于可达性、元数据配置、角色信任、下游策略还是工作负载绑定环节。
  • 如果挑战内容聚焦于凭证发放后的RBAC或集群变更操作，请切换到更适配的控制平面技能。

Read This Reference

参考资料说明

  • Load 
    references/cloud-metadata-path.md
    for the reachability checklist, token checklist, and evidence packaging.
  • If the hard part is first proving a server-side fetch primitive, SSRF reachability, or internal endpoint traversal before metadata itself, prefer 
    $competition-ssrf-metadata-pivot
    .
  • 加载
    references/cloud-metadata-path.md
    获取可达性检查清单、令牌检查清单和证据打包规范。
  • 如果难点在于在访问元数据之前，首先要证明服务端获取原语、SSRF可达性或内部端点遍历能力，请优先使用
    $competition-ssrf-metadata-pivot
    。

What To Preserve

需要留存的内容

  • Metadata endpoints, required headers, reachability path, issued tokens or creds, and accepted APIs
  • Role names, audiences, issuers, account bindings, and privilege-bearing actions
  • The smallest replayable metadata-to-privilege chain
  • 元数据端点、必填请求头、可达路径、发放的令牌或凭证、可接受的API
  • 角色名称、受众、签发者、账户绑定关系和携带权限的操作
  • 可复现的最短元数据转权限链路