auditing-init-and-sidecar-injection-trustlisted

# Auditing init and sidecar injection trust: the containers you did not write share your pod A pod is not just its application container. Init containers run first, sidecars run alongside, and many are injected automatically by a mutating admission webhook that the workload owner never sees in their manifest. All of them share the pod: the same network namespace, often shared volumes, sometimes the process namespace, and they can be granted their own security context and credentials. That makes every init and sidecar container a trust question the main container did not ask. An injected sidecar may run privileged or with host access the app never needed; an init container may fetch and execute remote content before the app starts; a shared secret volume or process namespace lets a sidecar read the application's secrets; and the injected image and its configuration may come from a source outside the workload owner's control. The pod looks like one workload but is a collection of containers with different privileges and origins. You audit this by enumerating every init and sidecar container, declared and injected, and checking what trust each holds. ## When to use - Pods run init or sidecar containers, especially ones injected by a mutating admission webhook. - An injected or auxiliary container may run with broader privilege, host access, or credentials than the app. - Init containers fetch or execute content, or sidecars share volumes or namespaces with the main container.