Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
1–10 of 17 posts
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#2[deleted]
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#3How does this affect CaaS-based deployments like AKS, EKS, GKE and the like?
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#4How does this affect CaaS-based deployments like AKS, EKS, GKE and the like?
I doubt any of those use dockerd. They likely all use containerd directly.
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#5Hmmm... It's as though running root privelege daemons with open sockets could go wrong. Who could have known.
https://developers.redhat.com/blog/2020/09/25/rootless-conta...
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#6Are 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.
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#7How does this affect CaaS-based deployments like AKS, EKS, GKE and the like?
They are not using Docker for container runtime. It was deprecated in Kubernetes 1.20 and removed in 1.24 with almost everyone switching to containerd. Currently supported Kubernetes versions are 1.28/1.29/1.30. 1.27 is available as LTS from a few providers.
EDIT: Coworker mentioned there is a cri that lets you to continue to use Docker Engine in Kubernetes but I've never run across it.
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#8Are 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). ju…
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?
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#9Are 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). ju…
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.
Re: Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
#10> The vulnerability was addressed with the release of Docker Engine v18.09.1, but it was not included in subsequent major versions, causing a regression.
Without further information, this sounds like code introduced in a hotfix that wasn't merged back to feature branches.
Surely it's not that simple?