competition-container-runtime

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Chinese

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 challenge is really about what the live container or pod is doing now, not what the checked-in manifest claims it should do.

Reply in Simplified Chinese unless the user explicitly requests English.

仅可在

$ctf-sandbox-orchestrator

已激活并完成沙箱假设、节点归属及证据优先级确立后，作为下游专用技能使用。若尚未满足前述条件，请先返回

$ctf-sandbox-orchestrator

。

当挑战的核心是运行中的容器或Pod当前的实际行为，而非已提交的manifest声明的预期行为时，使用本技能。

除非用户明确要求使用英文，否则请使用简体中文回复。

Split intent from reality: manifest, image, startup, live mount, live route, live process.
Map host -> proxy -> container or pod -> mounted volume -> consuming process.
Keep secrets, rendered config, init output, and sidecar output separate from static manifests.
Prove one minimal live path from mounted or injected state to reachable behavior.
Reproduce the effect with the smallest runtime-specific chain.

Compare compose or kube manifests against running containers, pods, mounted volumes, env, sidecars, init containers, and entrypoints.
Identify which process actually consumes the mounted secret, rendered config, or shared volume output.

Map virtual host, reverse proxy, service, container port, filesystem mount, and runtime-generated file paths together.
Record whether the decisive state is image-baked, env-injected, mounted later, or written by an init/sidecar process.

State the earliest point where live runtime diverges from checked-in intent.
Keep one compact evidence chain from manifest or compose intent to live consumer behavior.

Load
```
references/container-runtime.md
```
for the runtime checklist, mount-chain checklist, and common live-vs-static pitfalls.
If the hard part is kube API permissions, service-account trust, RBAC edges, admission mutations, or controller-created workload drift, prefer
```
$competition-k8s-control-plane
```
.
If the hard part is Host-header routing, path-prefix rewriting, or route-to-service mapping across nodes, prefer
```
$competition-runtime-routing
```
.
If the hard part is proving container-to-host crossover, kernel attack-surface preconditions, or stable escape primitives, prefer
```
$competition-kernel-container-escape
```
.
If the hard part is replaying Linux secrets, socket trust edges, or host-to-host pivots after container foothold, prefer
```
$competition-linux-credential-pivot
```
.

加载
```
references/container-runtime.md
```
查看运行时检查清单、挂载链路检查清单及常见的运行态vs静态配置陷阱。
若核心难点是kube API权限、服务账户信任、RBAC边界、准入变更或控制器创建的工作负载漂移，请优先使用
```
$competition-k8s-control-plane
```
。
若核心难点是Host-header路由、路径前缀重写或跨节点的路由到服务映射，请优先使用
```
$competition-runtime-routing
```
。
若核心难点是证明容器到主机的穿透、内核攻击面前置条件或稳定逃逸原语，请优先使用
```
$competition-kernel-container-escape
```
。
若核心难点是拿到容器权限后重放Linux密钥、套接字信任边界或主机间横向移动，请优先使用
```
$competition-linux-credential-pivot
```
。

Compose/Kubernetes fragments tied to live mounts or routes
Container IDs, pod names, mount paths, sidecar outputs, rendered config paths, and consuming processes
The exact route or file path that becomes reachable only at runtime