auditing-container-runtime-and-socket-exposurelisted

# Auditing container runtime and socket exposure: a handle on the runtime is a handle on the host Access to the container runtime is access to the host, full stop. Whoever can talk to the runtime socket or API can start a new container that is privileged, mounts the host root filesystem, and shares the host namespaces, and from there they own the node. So mounting the runtime socket into a pod, or binding it into a build or CI container, is not a convenience; it is handing that workload the ability to escape to the host by design, no kernel bug required. The pattern shows up wherever tooling genuinely needs the runtime, image builds, node agents, CI that builds containers, and the mistake is granting broad runtime access for a narrow need. The audit is direct: find every workload that can reach the runtime and treat that reach as host control unless it is tightly brokered. You audit this by locating runtime-socket mounts and runtime-API reachability and confirming nothing untrusted holds them. ## When to use - A workload, build container, or agent is given the container runtime socket or access to the runtime API. - A sidecar or tool talks to the runtime to build, launch, or inspect containers. - The runtime API may be exposed over a reachable port rather than a local, access-controlled socket. ## Scope check Audit runtime exposure only on hosts and clusters you own or are authorized to assess, on non-production nodes. Demonstrating runtime access can launch a container