We replicated the behavior (somewhat) of the article, using podman, as a way to allow devs to SSH into a container that was identical to the CI/CD environment. It also mapped in their NFS home drive, so they could quickly SSH into the container to try a build, to see if it was their dev machine, or a real issue. It did allow them to choose their container though.

https://github.com/SEL4PROJ/imagesh/tree/master

> Frankly, ssh-to-container is a "slaps forehead" obvious solution and I'm surprised none of us thought of it before

I think CNCF is at the point where you can assume that "there's a CNCF project for that" is true for anything container/kubernetes related.

https://www.cncf.io/projects/containerssh/

I'm not sure if the attack surface is effectively reduced with the use of cointainers. Of course, the user is now in his own namespace, but in order to achieve this, an additional file system, another network interface and a container runtime have been added, thus effectively doubling the complexity. Containers are great if you want to present a service to the outside world or if you want to set up a clean workspace locally. But I wouldn't be comfortable with the thought of letting someone I don't trust into the server behind the firewall. Depending on the configuration, you can reach other local containers via localhost:${port}. An with overlayfs there was afaik a case where you could actually access restricted areas of the underlying filesystem.

These arguments are painting a bike shed: the attack surface is not zero but it's still dramatically reduced and controlled. Nobody said anything about "letting someone I don't trust into the server behind the firewall" which of course is (cough) "not best practice."

Also, containers mean that one user can make changes (install/upgrade software, etc) and not adversely affect another user (incl their security stance).