competition-cloud-metadata-path

競技会クラウドメタデータパス

このスキルは、$ctf-sandbox-orchestrator がすでにアクティブで、サンドボックスの前提、ノードの所有権、証拠の優先順位が確立されている場合にのみ、その下流の専門特化として使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。

このスキルは、決定的な優位性が単にメタデータに到達することではなく、メタデータ由来のアイデンティティがどのようにして受け入れられる権限になるかを証明することにある場合に使用します。

ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。

クイックスタート

1. どのメタデータサーフェスがアクティブかを特定します。インスタンスメタデータ、ワークロードアイデンティティ、ノードアイデンティティ、タスクロール、またはプラットフォーム固有のトークンエンドポイントです。
2. 正確な到達経路を記録します。ローカルプロセス、Pod、コンテナ、プロキシ、SSRF サーフェス、またはホストルートです。
3. メタデータへの到達可能性を、認証情報の発行および下流での権限受け入れから切り分けます。
4. トークン形式、ロールアイデンティティ、スコープ、および受け入れる API をコンパクトな証拠ブロックにまとめます。
5. チャレンジの優位性を証明する、最小のメタデータから受け入れられる権限への経路を再現します。

ワークフロー

1. メタデータの到達可能性をマッピングする

• メタデータエンドポイント、必要なヘッダー、ホップ制限、セッショントークン、ワークロードセレクター、またはパスプレフィックスを記録します。
• アクセスが直接のローカル呼び出し、Pod ネットワーキング、SSRF、サイドカー、またはホストレベルのルーティングのいずれから来るかを記録します。
• 到達するサーフェスとメタデータエンドポイントを 1 つのチェーンにまとめます。

2. 認証情報またはアイデンティティの発行を証明する

• メタデータ応答がどのようにトークン、一時認証情報、署名済みアイデンティティドキュメント、またはプラットフォーム固有のワークロードアイデンティティになるかを示します。
• 下流で重要となる有効期限、ロール名、サブジェクト、オーディエンス、発行者、またはクラウドアカウントのマッピングを記録します。
• 生のメタデータと使用可能な認証情報素材を区別します。

3. 決定的な信頼パスへと絞り込む

• 結果を最小のシーケンスに圧縮します。到達するサーフェス -> メタデータ呼び出し -> 認証情報の発行 -> 受け入れられるクラウドまたはクラスタのアクション。
• 弱点が到達可能性、メタデータ設定、ロールの信頼、下流のポリシー、またはワークロードバインディングのどこにあるかを明確に述べます。
• チャレンジが認証情報発行後の RBAC またはクラスタ変更に絞られる場合は、より厳密なコントロールプレーンのスキルに戻ってください。

このリファレンスを読む

• 到達可能性チェックリスト、トークンチェックリスト、および証拠のパッケージ化については references/cloud-metadata-path.md を読み込んでください。
• 難しい部分が、メタデータそのものよりも前に、まずサーバーサイドフェッチプリミティブ、SSRF 到達可能性、または内部エンドポイントトラバーサルを証明することである場合は、$competition-ssrf-metadata-pivot を優先してください。

保持すべきもの

• メタデータエンドポイント、必要なヘッダー、到達経路、発行されたトークンまたは認証情報、および受け入れられる API
• ロール名、オーディエンス、発行者、アカウントバインディング、および権限を伴うアクション
• 最小の再現可能なメタデータから権限へのチェーン