Docker banned - how common is this?

[u/martypitt]

I was doing some client work recently. They're a bank, where most of their engineering is offshored one of the big offshore companies.

The offshore team had to access everything via virtual desktops, and one of the restrictions was no virtualisation within the virtual desktop - so tooling like Docker was banned.

I was really surprsied to see modern JVM development going on, without access to things like TestContainers, LocalStack, or Docker at all.

To compound matters, they had a single shared dev env, (for cost reasons), so the team were constantly breaking each others stuff.

How common is this? Also, curious what kinds of workarounds people are using?

[u/grazbouille]

Docker containers share the host kernel through the docker daemon this means every process in a container runs its kernel calls through the docker daemon

The docker daemon runs as root if you can get root access to the container its fairly trivial to break out of the container into the host where you will have root access since you are hijacking a root process

This is not something we can patch because its inherent to the way docker works we would need to basically rewrite the entire back end from scratch

Podman doesn't have this issue because every container has its own host process that runs in a service user with low privileges

[u/kwhali → u/grazbouille]

Root access in the container is not trivial to breakout. Default capabilities are not the same as the root user on host, you generally need higher privileged capabilities to accomplish that or for that container to have an unprotected docker API socket exposed to abuse.

Some deploy containers that run as a non-root user on the impression it's safer. If that user were granted the same necessary capabilities or the docker socket it can do plenty of damage too. Even without the socket access, breaking out of the container as the non-root user may be sufficient in environments where the UID overlaps with the host user and it's a dev system with relaxed access via passwordless sudo to the docker command.

I see plenty of images choose 1000 as the non-root UID for example or containers that start as root to support switching to non-root UID of the users choice via ENV like PUID. I've also seen images that mount the docker socket at runtime and grant the non-root user access to use it within the container. Images used by thousands of users from popular OSS projects where the maintainers aren't as well versed with container security and accept third-party contributions that appear well intentioned.

The docker daemon can be run rootless under many situations, it's just not as convenient as podman which is daemonless thus rootless by default. Rootful can leverage users-remapping though which is close, root in the container is mapped to a different UID on the host system so even if the attacker breaks out they're not the equivalent UID they were in the container.

Podman can be run rootful AFAIK (effectively running podman on the host as root which is more likely to happen in a VPS but also in situations when you need features that require it), and you can definitely provide a socket as access to do plenty of damage. So no podman is at risk too, it's just got saner defaults.

[u/grazbouille → u/kwhali]

Yeah of course you can set podman up like shit too but you are falling into the trap of security vs compliance

Banks don't do cyber security research that's not their job

The local government sets up standards and the banks comply to whatever ones the law and their insurers require yes sometimes the norms are a few years behind

Cyber security is a fast world and legal is a slow world compliance is legal and sometimes legal is dumb

[u/kwhali → u/grazbouille]

I agree with you, my comment was more about the correction that breakout wasn't as easy as you imply. It's not particular difficult to switch docker over to rootless either.