With Kubernetes 1.6 came the beta release of the role-based access control (RBAC) feature. This feature allows admins to create policies defining which users can access which resources within a Kubernetes cluster or namespace. Kubernetes itself does not have a native concept of users and instead delegates to an external authentication system. As of version 1.6.3, Rancher integrates with this process to allow any authentication system supported by Rancher, such as Github, LDAP, or Azure AD, to be used for Kubernetes RBAC policies. In short, Rancher v1.6.3 picks up where Kubernetes RBAC leaves off, giving teams a dead-easy mechanism for authenticating users across their Kubernetes clusters.
To see how one might use this feature, let’s consider a company that has a development team and a QA team. Let’s also suppose they’re using GitHub as the authentication method for their Rancher setup. In their Kubernetes environment they’ve created two namespaces, one for developers and one for QA. It’s now possible for admins to define rules such as the following:
Only members of the “developers” Github team should have read and write access to the “dev” namespace
Likewise, only members of the “QA” Github team should have read and write access to the “QA” namespace
Developers should also be able to view, but not edit, resources in the “QA” namespace
Users “user1” and “user2” should be able to read and write to both the “dev” and “QA” namespaces
Other Kubernetes features can be leveraged to more richly define multitenancy within a Rancher Kubernetes environment. With resource quotas, an admin can define limits on resources such as CPU and memory usage for a namespace. This is particularly important since namespaces within an environment run on the same set of hosts.
Role bindings follow the pattern of tying a particular role to one or more users or one or more groups. The preceding example made use of three built-in roles defined by Kubernetes:
view: Read-only access to most objects in a namespace
edit – Read and write access to most objects in a namespace
admin – Includes all permissions from the edit role and allows the creation of new roles and role bindings
These predefined roles enhance the usability of RBAC by allowing most users to reuse these roles in place of defining their own. We recommend using these roles for those who are less familiar with individual Kubernetes resources or for those who don’t have a need to define their own custom roles.
From our work with teams running Kubernetes in production, particularly those offering CaaS solutions across their organizations, we understand the need for straightforward RBAC, authentication, and authorization. More detailed information on this feature can be found in our docs. We always want feedback on what we’re building for Rancher and Kubernetes – for any questions, you can find me on Rancher Users Slack (@josh) or on Twitter (@joshwget).
Join us for free online training courses, hosted monthly by a Rancher technical expert. We provide a great hands-on overview for new users setting up a Rancher deployment, and answer any and all questions you have about Rancher and how to integrate it into your DevOps processes!