Configuring permissions in Kubernetes with RBAC

Jul 26, 2018 · 5 min read
Kai Pilger via

by Nikita Mazur

Ensuring the control of who has access to your Information System and what users have access to is the objective of an Identity and Access management system. It is one of the fundamental processes in the Security Management and it should be thoroughly taken care of.

In Kubernetes, Identity and User management are not integrated in the platform and should be managed by external IAM platforms like Keycloak, Active Directory, Google’s IAM, etc. However, authentication and authorization are handled by Kubernetes.

In this article we will be focusing on the authorization aspects of the IAM in Kubernetes, and more specifically on how to make sure a user has the right permissions towards the right resources using the Role-Based Access Control model.


RBAC is a stable feature from Kubernetes 1.8. In this article we will assume that you are using Kubernetes 1.9+. We will also assume that RBAC has been enabled in your cluster through the --authorization-mode=RBAC option in your Kubernetes API server. You can check this by executing the command kubectl api-versions; if RBAC is enabled you should see the API version

Overview of RBAC concepts in Kubernetes

The RBAC model in Kubernetes is based on three elements:

  • Roles: definition of the permissions for each Kubernetes resource type
  • Subjects: users (human or machine users) or groups of users
  • RoleBindings: definition of what Subjects have which Roles

Let’s explore how these elements work.

In the example below you can see a Role which allows to get, list and watch pods in the namespace “mynamespace”:

To give a user the permissions described in the previous Role it is necessary to create a RoleBinding. In the example below, the RoleBinding “example-rolebinding” binds the Role “example-role” to the user “example-user”:

It should be noted that Roles and RoleBindings are namespaced, which means that the permissions can only be given for the Kubernetes resources that are in the same namespace as the Role and the RoleBinding. Also, it is without saying that a RoleBinding can only reference a Role that exists in its namespace.

Roles, ClusterRoles, RoleBindings and ClusterRoleBindings

In the previous example we have used Roles and RoleBindings. But, there is also the possibility to use ClusterRoles and ClusterRoleBindings which are useful in the following cases:

  • Give permissions for non-namespaced resources like nodes
  • Give permissions for resources in all the namespaces of a cluster
  • Give permissions for non-resource endpoints like /healthz

The definitions of the cluster scoped versions of Roles and RoleBindings are very similar to the non-cluster scoped ones. If we take the previous example and adapt it, we will have the following definitions. ClusterRole:


How to enable permissions in Roles and ClusterRoles

In the first example we granted basic permissions to a user to get, watch and list pods. Let’s explore other possibilities we have for the different resources and permissions.

In the example below the Role allows to perform any actions with a Deployment resource:

Notice that in this case the apiGroups field has been filled in with the API group of the Deployment. Depending on the Kubernetes version, the Deployment resource is available in the API apps/v1 or extensions/v1beta2; the API group is the part before the slash.

We can have multiple rules defined in a Role, like in the example below:

In this case we grant different permissions depending on whether the targeted resource is a Pod or a Job.

We can also target a resource by its name, like in the following example:

How to bind a Subject to a Role or a ClusterRole

In the first example we have seen how to bind a human user to a Role. However, there is also the possibility to bind a service account (non-human user) or a group of human users and/or service accounts.

In the example below, the RoleBinding example-rolebindingbinds the ServiceAccount example-sto the Role example-role:

You can create a ServiceAccount with the following command:

In the previous RoleBinding definition we can also replace the subject to bind a group. In the example below, we bind the frontend-adminsgroup:

Another possibility is to bind group of service accounts. Here we bind all the service accounts in the mynamespacenamespace:

Or all the service accounts in the cluster:

One last thing about RBAC in Kubernetes

We have seen how to grant permissions to a user or a service account using the Role-based Access Control model. It is an efficient way to implement authorization in Kubernetes, and it is probably the most popular one, but it is not the only model available: you can also use other models like ABAC (Attribute-based access control), Node Authorization model and the Webhook mode. We will be describing these in further articles, along with another IAM feature in Kubernetes: authentication.

See you soon, protect your cluster and stay safe!

Feel free to leave your feedback. Don’t forget to follow us on Twitter and join our Telegram chat to stay tuned!

You might also want to check our Containerum project on GitHub. We really need your feedback to make it stronger — you can submit an issue, or just support the project by giving it a ⭐. Your support matters to us!

Containerum is your source of knowledge on Kubernetes.


Containerum publishes articles and best practices on…


Containerum publishes articles and best practices on Kubernetes. Containerum has just released an open source management platform with built-in revision control, teamwork and CI/CD pipelines.


Written by

Containerum Platform for managing applications in Kubernetes.


Containerum publishes articles and best practices on Kubernetes. Containerum has just released an open source management platform with built-in revision control, teamwork and CI/CD pipelines.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store