Tag: rbac

Understanding Kubernetes RBAC

November 22, 2017

The general availability (GA) release of Rancher 2.0 draws closer by the day. In this post, we’ll explore the fine control you will have over your Rancher 2.0 deployments when you leverage the role-based access control (RBAC) that Kubernetes brings to the platform.
Read more

Kubernetes Authentication in Rancher and RBAC

September 22, 2017

As of version 1.6.3, Rancher introduced the Role-Based Access Control (RBAC) feature in Kubernetes. This feature allows admins to configure different policies that allow or deny access for users and service accounts to Kubernetes API resources.

To better understand how the RBAC feature works, this post will shed light on how authentication works with the Kubernetes API, and how the RBAC authorization module works with authenticated users. Read more

RBAC, Kubernetes, and Rancher

July 10, 2017

kubernetesWith 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).


Josh Curl is a software engineer at Rancher Labs. 

Upcoming Events

Recent Posts