competition-container-runtime

コンペティションコンテナランタイム

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

このスキルは、チェックインされたマニフェストがそうするはずだと主張している内容ではなく、実際に稼働中のコンテナまたはポッドが現在何を行っているかが課題の本質である場合に使用してください。

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

クイックスタート

1. 意図と現実を切り分けます: マニフェスト、イメージ、起動、ライブマウント、ライブルート、ライブプロセス。
2. ホスト -> プロキシ -> コンテナまたはポッド -> マウントされたボリューム -> 消費プロセスをマッピングします。
3. シークレット、レンダリングされた設定、init 出力、サイドカー出力を静的なマニフェストから分離して保持します。
4. マウントまたは注入された状態から到達可能な動作までの、最小限のライブパスを 1 つ証明します。
5. 最小のランタイム固有のチェーンでその効果を再現します。

ワークフロー

1. ライブランタイムをマッピングする

• compose または kube マニフェストを、稼働中のコンテナ、ポッド、マウントされたボリューム、env、サイドカー、init コンテナ、エントリポイントと比較します。
• マウントされたシークレット、レンダリングされた設定、または共有ボリューム出力を実際に消費しているプロセスを特定します。

2. ルートとマウントの境界を追跡する

• バーチャルホスト、リバースプロキシ、サービス、コンテナポート、ファイルシステムマウント、ランタイム生成ファイルパスをまとめてマッピングします。
• 決定的な状態が、イメージに焼き込まれているのか、env で注入されているのか、後からマウントされているのか、init/サイドカープロセスによって書き込まれているのかを記録します。

3. ランタイムの逸脱を報告する

• ライブランタイムがチェックインされた意図から逸脱する最も早い時点を述べます。
• マニフェストまたは compose の意図からライブの消費側の動作までの、コンパクトな証拠チェーンを 1 つ保持します。

このリファレンスを読む

• ランタイムチェックリスト、マウントチェーンチェックリスト、および一般的なライブ対静的の落とし穴については、references/container-runtime.md を読み込んでください。
• 難しい部分が kube API の権限、サービスアカウントの信頼、RBAC のエッジ、アドミッションの変更、またはコントローラーが作成したワークロードのドリフトである場合は、$competition-k8s-control-plane を優先してください。
• 難しい部分が Host ヘッダーのルーティング、パスプレフィックスの書き換え、またはノード間のルートからサービスへのマッピングである場合は、$competition-runtime-routing を優先してください。
• 難しい部分がコンテナからホストへのクロスオーバーの証明、カーネル攻撃面の前提条件、または安定したエスケーププリミティブである場合は、$competition-kernel-container-escape を優先してください。
• 難しい部分がコンテナの足がかり後の Linux シークレットの再生、ソケットの信頼エッジ、またはホスト間ピボットである場合は、$competition-linux-credential-pivot を優先してください。

保持すべきもの

• ライブマウントまたはルートに紐づく Compose/Kubernetes フラグメント
• コンテナ ID、ポッド名、マウントパス、サイドカー出力、レンダリングされた設定パス、消費プロセス
• ランタイム時にのみ到達可能になる正確なルートまたはファイルパス