4 ms·

Are there really good use cases for dockerd being exposed to the network? I would assume (many/most) users who run docker directly run it without api access on

Are there really good use cases for dockerd being exposed to the network? I would assume (many/most) users who run docker directly run it without api access on the network (i.e. on a single host). Even those that do want network deployments of docker, probably run it through something like k8s where again kubernetes is handling the networking side, and each dockerd doesn't need to expose a network accessible api). just wondering the use case for this.

claytonjy 2y ago
My first thought was CI providers, where we often have to specify a "service" to allow `docker build`. I don't know much about the internals there; would this bug allow me to do bad stuff on shared CI runners?
radus 2y ago
Example: you want to set your local docker context to the production environment, so that when you type `docker system prune --volumes` you delete your production data.
- awithrow 2y ago
  Honestly this sounds like a massive outage waiting to happen
  - hotsauceror 2y ago
    That’s Ops’s problem later tonight. You have to move fast and break things.
- rudasn 2y ago
  Right? I always wondered who would use that feature and for what, now it all makes sense!
hibbelig 2y ago
Docker desktop for Mac: dockerd runs in the VM and the client from the host system wants to connect. But of course we all hope that the network it is exposed to is still only on the Mac.
chatmasta 2y ago
The issues arise when “the network” means something different at deployment time. You might plan or expect “the network” to be shared only by local services. But then you add some management GUI that needs access to it. And then you add a sidecar to that. And before you know it, you’ve got a bunch of containers, all with their own attack surface, and all with access to the dockerd socket.
m463 2y ago
related, note that docker will money with the firewall and let itself through unexpectedly: https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker....

claytonjy 2y ago

My first thought was CI providers, where we often have to specify a "service" to allow `docker build`. I don't know much about the internals there; would this bug allow me to do bad stuff on shared CI runners?

radus 2y ago

Example: you want to set your local docker context to the production environment, so that when you type `docker system prune --volumes` you delete your production data.

awithrow 2y ago
Honestly this sounds like a massive outage waiting to happen
- hotsauceror 2y ago
  That’s Ops’s problem later tonight. You have to move fast and break things.
rudasn 2y ago
Right? I always wondered who would use that feature and for what, now it all makes sense!

hibbelig 2y ago

Docker desktop for Mac: dockerd runs in the VM and the client from the host system wants to connect. But of course we all hope that the network it is exposed to is still only on the Mac.

chatmasta 2y ago

The issues arise when “the network” means something different at deployment time. You might plan or expect “the network” to be shared only by local services. But then you add some management GUI that needs access to it. And then you add a sidecar to that. And before you know it, you’ve got a bunch of containers, all with their own attack surface, and all with access to the dockerd socket.

m463 2y ago

related, note that docker will money with the firewall and let itself through unexpectedly: https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker....