$npx -y skills add zhaoxuya520/reverse-skill --skill competition-cloud-metadata-pathInternal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for cloud metadata services, instance identity, workload identity, link-local credential paths, role assumption, and metadata-to-privilege trust edges. Use when the user asks to inspect metadata-service
| 1 | # Competition Cloud Metadata Path |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | Use this skill when the decisive edge is not just reaching metadata, but proving how metadata-derived identity becomes accepted privilege. |
| 6 | |
| 7 | Reply in Simplified Chinese unless the user explicitly requests English. |
| 8 | |
| 9 | ## Quick Start |
| 10 | |
| 11 | 1. Identify which metadata surface is active: instance metadata, workload identity, node identity, task role, or platform-specific token endpoint. |
| 12 | 2. Record the exact reachability path: local process, pod, container, proxy, SSRF surface, or host route. |
| 13 | 3. Separate metadata reachability from credential issuance and from downstream privilege acceptance. |
| 14 | 4. Keep token format, role identity, scope, and accepting API in compact evidence blocks. |
| 15 | 5. Reproduce the smallest metadata-to-accepted-privilege path that proves the challenge edge. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | ### 1. Map Metadata Reachability |
| 20 | |
| 21 | - Record the metadata endpoint, required headers, hop limits, session tokens, workload selectors, or path prefixes. |
| 22 | - Note whether access comes from direct local calls, pod networking, SSRF, sidecar, or host-level routing. |
| 23 | - Keep the reaching surface and the metadata endpoint in one chain. |
| 24 | |
| 25 | ### 2. Prove Credential Or Identity Issuance |
| 26 | |
| 27 | - Show how the metadata response becomes a token, temporary credential, signed identity doc, or platform-specific workload identity. |
| 28 | - Record expiration, role name, subject, audience, issuer, or cloud account mapping that matters downstream. |
| 29 | - Distinguish raw metadata from usable credential material. |
| 30 | |
| 31 | ### 3. Reduce To The Decisive Trust Path |
| 32 | |
| 33 | - Compress the result to the smallest sequence: reaching surface -> metadata call -> credential issued -> accepted cloud or cluster action. |
| 34 | - State clearly whether the weakness lives in reachability, metadata config, role trust, downstream policy, or workload binding. |
| 35 | - If the challenge narrows to RBAC or cluster mutation after credential issuance, switch back to the tighter control-plane skill. |
| 36 | |
| 37 | ## Read This Reference |
| 38 | |
| 39 | - Load `references/cloud-metadata-path.md` for the reachability checklist, token checklist, and evidence packaging. |
| 40 | - 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`. |
| 41 | |
| 42 | ## What To Preserve |
| 43 | |
| 44 | - Metadata endpoints, required headers, reachability path, issued tokens or creds, and accepted APIs |
| 45 | - Role names, audiences, issuers, account bindings, and privilege-bearing actions |
| 46 | - The smallest replayable metadata-to-privilege chain |