RBAC, Kubernetes, and Rancher | SUSE Communities

RBAC, Kubernetes, and Rancher



Update: The topic of Role-Based Access Control (RBAC) was addressed again and updated by Craig Jellick here.

With Kubernetes 1.6 came the
beta release of the role-based access control (RBAC)
. 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
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
, 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 RBAC 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 foundin our
. We
always want feedback on what we’re building for Rancher and Kubernetes
– for any questions, you can find me on Rancher Users

(@josh) or on Twitter
(@joshwget). *Josh Curl is a software
engineer at Rancher Labs. *