When a minimal image has no shell, kubectl exec fails. Use kubectl debug to add an ephemeral container with the tools you need to the running pod, and point it at the target container's process namespace. The production image stays small and you still get a shell to investigate.
Why this problem appears
Teams shrink images to remove tools an attacker could use. The Kubernetes documentation on ephemeral containers acknowledges the tradeoff. It says minimal images reduce attack surface and exposure to bugs and vulnerabilities, but that since they include no shell or debugging utilities, they are difficult to troubleshoot with exec alone.
The old workaround was to add a shell to the image "just in case". That defeats the point. Ephemeral containers let you keep the image lean and bring tools only when needed.
The steps
The Kubernetes debug guide walks through this with an image that has no shell. Trying to exec into it fails with an executable not found error. Then:
kubectl debug -it POD_NAME --image=busybox:1.28 --target=CONTAINER_NAME
The command adds a new container to the pod and attaches to it. The target option points at the process namespace of another container. The docs explain it is needed when the pod was created without process namespace sharing. They also warn that the target option must be supported by the container runtime. If it is not, the ephemeral container may not start, or may start with an isolated process namespace so process listing does not show the other containers.
Afterwards, describing the pod shows an Ephemeral Containers section.
Other options in the same guide
If you cannot touch the live pod, debug a copy.
kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
The share-processes option lets the containers in the copy see each other's processes. You can also change the command of a container in the copy, or swap the image of all containers with the set-image option. Delete the copy when finished.
Limits to remember
From the ephemeral containers page:
- They have no guarantees for resources or execution and are never automatically restarted.
- Ports, probes and resources fields are not allowed.
- They are added through a special API handler, so kubectl edit cannot add one.
- You cannot change or remove one after adding it. The pod keeps it until the pod is gone.
- Static pods do not support them.
The feature has been stable since Kubernetes v1.25.
Security notes
A debug container is powerful. Anyone who can create one in a namespace can run arbitrary commands next to your app and see its processes. Treat that permission like shell access to production.
- Limit the RBAC permission to a small group.
- Log and review its use.
- Use a trusted debug image from a registry you control, and pin it.
- Delete the pod afterwards, since the ephemeral container cannot be removed on its own.
For a related decision about what belongs in the production image at all, see multi-stage builds.
Safeguard's SBOM and dependency scanning lets you confirm what your minimal image really contains, and a free scan is a place to start.
Quick check
Can I just add busybox to the production image?
You can, but it gives an intruder the same tools. Ephemeral containers keep those tools out of the shipped image.
Does kubectl debug change the running app container?
It adds a container to the pod. The app container keeps running as before. Using the copy option avoids touching the live pod at all.
Sources
Last reviewed: 19 October 2026.
