Skip to content
Securely manage Docker, Swarm, Kubernetes and Podman clusters in the cloud, on-premise, and in the data center.
Secure app deployment and device management for your Industrial IoT, IoT and Edge devices.
Let Portainer's Managed Platform Services accelerate your containerization journey.
Manage all your Docker, Swarm, Kubernetes and Podman clusters from a single secure interface.
Portainer empowers Platform Engineering teams to deliver efficient, user-centric services.
Empower your business by adopting containerization the easy way with Portainer.
Deploy to and manage your fleet of remote devices centrally and securely.
Onboard, manage and deploy workloads across hundreds of devices securely with Portainer.
Deployment scenarios
Partner Solutions
blog-banner
Neil Cresswell, CEOMarch 17, 20222 min read

Docker Desktop Kubernetes NOT enforcing RBAC rules

So here is a little golden nugget of awesomeness that might just save you a TON of time (as it wasted hours of my time trying to triage why the RBAC rules Portainer was trying to set were being ignored).

NOTE THIS HAS NOW BEEN RESOLVED AS OF DOCKER DESKTOP VERSION 4.3.0 (Dec 2021), either update to the new version (and reset your Kubernetes instance) or follow the info below for a workaround.

If you are using Docker Desktop, and their embedded Kubernetes offering, you may not be aware but, by default it does NOT enforce any RBAC rules. It will let you create RBAC rules, but it wont enforce them.

Why?

Because Docker made a design descision (in the name of simplicity) to make ALL service accounts automatically receive cluster-admin role BY DEFAULT.

The Role Binding they set is as below:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: docker-for-desktop-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
If you want to reverse this design decision, you simply need to run "kubectl delete clusterrolebinding docker-for-desktop-binding" and then like magic (and like every other Kubernetes distro out there!!), it will start enforcing RBAC rules.

Docker actually state that they "fixed" this in Aug 2019, and their technical fix was to add: namespace: kube-system to the end of the "subjects" line, but that didn't actually resolve the issue (hence why I still ran into this issue today).

Repeated calls from Docker Desktop users to have Docker resolve this have seemingly fallen on deaf ears (see issue 4774 referenced below).

If you want to fix this yourself, first delete the clusterrolebinding, and then add a new one (similar to Docker's, but actually correct):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: docker-for-desktop-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:kube-system

We have subscribed to the open github issue on the docker desktop repo where people are asking for this to be resolved, and once we see it resolved, we will delete this post.

Hope this is helpful.

Neil

Links:
Original resported issue here (which was claimed as fixed): https://github.com/docker/for-mac/issues/3694

And the reopend issue that is seemingly going nowhere: https://github.com/docker/for-mac/issues/4774
avatar

Neil Cresswell, CEO

Neil brings more than twenty years’ experience in advanced technology including virtualization, storage and containerization.

COMMENTS

Related articles