Role-based Access Control for Kubernetes with Docker Enterprise
- January 17, 2020
This post was originally published on January 24, 2018 on the Docker blog.
Last week we released the latest beta for Docker Enterprise Edition 2.0. Without a doubt one of the most significant features in this release is providing a single management control plane for both Swarm and Kubernetes-based clusters – including clusters made up of both Swarm and Kubernetes workers. This offers customers unparalleled choice in how they manage both their traditional and cloud native applications.
When we were looking at doing this release we knew we couldn’t just slap a GUI on top of Kubernetes and call it good. We wanted to find areas where we could simplify and secure the deployment of applications onto Kubernetes nodes.
One such area is role-based access control (RBAC). Docker EE 17.06 introduced an enhanced RBAC solution that provided flexible and granular access controls across multiple teams and users. While Kubernetes first introduced a basic RBAC solution with the 1.6 release, in this upcoming release, we extend Docker EE’s existing RBAC support to support Kubernetes primitives.
In addition to the five predefined authentication roles in Docker EE (view only, full control, none, etc) there are 33 different categories of operations that administrators can use to create custom roles. And, each of these categories covers multiple different settings. For administrators this means they can mix and match between a set of sensible default roles for some users or creating highly-customized roles where needed.
For Khalil, Katherine setup a custom role that only allows a user to list pods. She then created a grant that gave Kahlil that role, but only for the ‘prod-web’ namespace.
Next, Katherine created a custom role that allows a user to list swarm services, and granted that role to Saavni for the ‘prod_db’ collection.
[youtubevideo url="https://youtu.be/VW8RQXeJYTs"]
As you would expect, Khalil is limited to that single namespace (prod-web) and all he can do is see what pods are running. He cannot modify those running pods, nor can he create new pods. And, of course, he cannot see any pods that might be running in other namespaces. These restrictions are applied whether Khalil is accessing the Kubernetes cluster via Docker EE’s Universal Control Plane or via the command line using a Docker EE client bundle and Kubectl.
[youtubevideo url="https://youtu.be/Bz_JXC9toMo"]
And, for Saavni, the same restrictions apply to the Swarm services running in our
[youtubevideo url="https://youtu.be/eLpmFeqEwN4"]
This is a pretty rudimentary example, but it should give you a good idea of the degree of flexibility that Docker EE’s RBAC implementation affords including being able to provide RBAC for both Kubernetes and Swarm using the same management paradigm, as well as having those controls work whether the applications are being managed via the GUI or CLI.
The integration of Kubernetes and Docker EE’s access controls is only one of the new features of the upcoming release. We’ve also done a lot of work to integrate Kubernetes with Docker Trusted Registry (as well as adding DTR image mirroring), made major improvements to our HTTP routing functionality.
To learn more about Docker Enterprise:
Last week we released the latest beta for Docker Enterprise Edition 2.0. Without a doubt one of the most significant features in this release is providing a single management control plane for both Swarm and Kubernetes-based clusters – including clusters made up of both Swarm and Kubernetes workers. This offers customers unparalleled choice in how they manage both their traditional and cloud native applications.
When we were looking at doing this release we knew we couldn’t just slap a GUI on top of Kubernetes and call it good. We wanted to find areas where we could simplify and secure the deployment of applications onto Kubernetes nodes.
One such area is role-based access control (RBAC). Docker EE 17.06 introduced an enhanced RBAC solution that provided flexible and granular access controls across multiple teams and users. While Kubernetes first introduced a basic RBAC solution with the 1.6 release, in this upcoming release, we extend Docker EE’s existing RBAC support to support Kubernetes primitives.
In addition to the five predefined authentication roles in Docker EE (view only, full control, none, etc) there are 33 different categories of operations that administrators can use to create custom roles. And, each of these categories covers multiple different settings. For administrators this means they can mix and match between a set of sensible default roles for some users or creating highly-customized roles where needed.
A Mixed Orchestrator RBAC Example
For Khalil, Katherine setup a custom role that only allows a user to list pods. She then created a grant that gave Kahlil that role, but only for the ‘prod-web’ namespace.
Next, Katherine created a custom role that allows a user to list swarm services, and granted that role to Saavni for the ‘prod_db’ collection.
[youtubevideo url="https://youtu.be/VW8RQXeJYTs"]
As you would expect, Khalil is limited to that single namespace (prod-web) and all he can do is see what pods are running. He cannot modify those running pods, nor can he create new pods. And, of course, he cannot see any pods that might be running in other namespaces. These restrictions are applied whether Khalil is accessing the Kubernetes cluster via Docker EE’s Universal Control Plane or via the command line using a Docker EE client bundle and Kubectl.
[youtubevideo url="https://youtu.be/Bz_JXC9toMo"]
And, for Saavni, the same restrictions apply to the Swarm services running in our
prod-db collection. Additionally, Saavni has no access to any Kubernetes resources, and Khalil has no access to any of the Swarm resources.[youtubevideo url="https://youtu.be/eLpmFeqEwN4"]
This is a pretty rudimentary example, but it should give you a good idea of the degree of flexibility that Docker EE’s RBAC implementation affords including being able to provide RBAC for both Kubernetes and Swarm using the same management paradigm, as well as having those controls work whether the applications are being managed via the GUI or CLI.
Authentication for Kubernetes Resources
So, how does it all work under the covers for the Kubernetes resources? Docker EE leverages the Kubernetes webhook authentication model. This feature enables the validation of all requests by an outside source. With Docker EE we use the control plane’s RBAC controller, eNZi. Each Kubernetes request, whether issued via the CLI or the GUI, is validated against Docker EE’s authN/authZ database, and then rejected or accepted as appropriate.The integration of Kubernetes and Docker EE’s access controls is only one of the new features of the upcoming release. We’ve also done a lot of work to integrate Kubernetes with Docker Trusted Registry (as well as adding DTR image mirroring), made major improvements to our HTTP routing functionality.
To learn more about Docker Enterprise:
