3 ms·

The regular shell is a huge attack surface, including user-to-user attacks and overly permissive network access. Frankly, ssh-to-container is a "slaps forehead

by asah 3y ago

The regular shell is a huge attack surface, including user-to-user attacks and overly permissive network access. Frankly, ssh-to-container is a "slaps forehead" obvious solution and I'm surprised none of us thought of it before - I'd love to see it as a standard option in the OS, e.g. chsh allows you to specify a container and optional port and volume mappings. In the old days, we'd (try to) use chroot, but that has all sorts of big problems with needing access to various directories, and those batches begat patches...

OlympusMonds 3y ago
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 https://github.com/SEL4PROJ/imagesh/tree/master
ndmrs 3y ago
> 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/ https://www.cncf.io/projects/containerssh/
mala-2 3y ago
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.
- asah 3y ago
  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).

by asah 3y ago

OlympusMonds 3y ago

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 https://github.com/SEL4PROJ/imagesh/tree/master

ndmrs 3y ago

> 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/ https://www.cncf.io/projects/containerssh/

mala-2 3y ago

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.

asah 3y ago
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).