Runtime de Contêineres de Competição

Use esta habilidade apenas como uma especialização downstream depois que $ctf-sandbox-orchestrator já estiver ativo e tiver estabelecido suposições de sandbox, propriedade do nó e prioridades de evidência. Se isso ainda não aconteceu, retorne para $ctf-sandbox-orchestrator primeiro.

Use esta habilidade quando o desafio for realmente sobre o que o contêiner ou pod ativo está fazendo agora, e não o que o manifesto registrado afirma que deveria fazer.

Responda em chinês simplificado, a menos que o usuário solicite explicitamente inglês.

Início Rápido

1. Separe intenção da realidade: manifesto, imagem, inicialização, montagem ativa, rota ativa, processo ativo.
2. Mapeie host -> proxy -> contêiner ou pod -> volume montado -> processo consumidor.
3. Mantenha segredos, configuração renderizada, saída de inicialização e saída de sidecar separadas dos manifestos estáticos.
4. Prove um caminho mínimo ativo do estado montado ou injetado para o comportamento alcançável.
5. Reproduza o efeito com a menor cadeia específica do runtime.

Fluxo de Trabalho

1. Mapeie o Runtime Ativo

• Compare os manifestos de compose ou kube com contêineres em execução, pods, volumes montados, env, sidecars, contêineres de inicialização e pontos de entrada.
• Identifique qual processo realmente consome o segredo montado, a configuração renderizada ou a saída do volume compartilhado.

2. Trace Limites de Rota e Montagem

• Mapeie juntos o host virtual, proxy reverso, serviço, porta do contêiner, montagem do sistema de arquivos e caminhos de arquivos gerados pelo runtime.
• Registre se o estado decisivo foi "cozido" na imagem, injetado via env, montado posteriormente ou escrito por um processo de inicialização/sidecar.

3. Relate o Desvio do Runtime

• Declare o ponto mais inicial onde o runtime ativo diverge da intenção registrada.
• Mantenha uma cadeia de evidências compacta da intenção do manifesto ou compose para o comportamento do consumidor ativo.

Leia esta Referência

• Carregue references/container-runtime.md para a lista de verificação do runtime, lista de verificação da cadeia de montagem e armadilhas comuns de runtime ativo vs. estático.
• Se a parte difícil for permissões da API kube, confiança de service-account, bordas de RBAC, mutações de admissão ou desvio de carga de trabalho criado por controlador, prefira $competition-k8s-control-plane.
• Se a parte difícil for roteamento Host-header, reescrita de prefixo de caminho ou mapeamento de rota para serviço entre nós, prefira $competition-runtime-routing.
• Se a parte difícil for provar a travessia de contêiner para host, pré-condições da superfície de ataque do kernel ou primitivas de escape estáveis, prefira $competition-kernel-container-escape.
• Se a parte difícil for reproduzir segredos do Linux, bordas de confiança de socket ou pivôs de host para host após o ponto de entrada do contêiner, prefira $competition-linux-credential-pivot.

O Que Preservar

• Fragmentos de Compose/Kubernetes vinculados a montagens ou rotas ativas
• IDs de contêineres, nomes de pods, caminhos de montagem, saídas de sidecar, caminhos de configuração renderizada e processos consumidores
• A rota exata ou caminho de arquivo que se torna alcançável apenas em tempo de execução