Having your Kubernetes cluster up and running is just the start of your journey and you now need to operate. To secure its access, user identities must be declared along with authentication and authorization properly managed. This article focus on how to create users with X.509 client certificates and how to manage authorizations with the basic Kubernetes Role-based access control (RBAC) API Objects. We will also talk about some open-source projects which simplify cluster administration: rakkess, kubectl-who-can, rbac-lookup, and RBAC Manager.

Prerequisites and assumptions

We need to make the following assumptions:

If you don’t have at your disposal a Kuberntes cluster, you can follow Arthur’s article Installing Kubernetes on CentOS 7 which uses Vagrant.

We have a 4 nodes Kubernetes cluster, one master and three workers. The master will also be used as our edge node to interact with the cluster.

RBAC API Objects

Role-based access control (RBAC) is a method of regulating access to computers and network resources based on the roles of individual users within an enterprise. We can use Role-based access control on all the Kubernetes resources that allow CRUD (Create, Read, Update, Delete). Examples of resources:

Examples of possible operations over these resources are:

  • create
  • get
  • delete
  • list
  • update

To manage RBAC in Kubernetes, we need to declare:

  • Role and ClusterRole
    They are just a set of rules that represent a set of permissions. A Role can only be used to grant access to resources within namespaces. A ClusterRole can be used to grant the same permissions as a Role but they can also be used to grant access to cluster-scoped resources, non-resource endpoints.
  • Subjects
    A subject is the entity that will make operations in the cluster. They can be user accounts, services accounts or even a group.
  • RoleBinding and ClusterRoleBinding
    As the name implies, it’s just the binding between a subject and a Role or a ClusterRole.

The default Roles defined in Kubernetes are:

We can, of course, create specific Roles and ClusterRoles, but we recommend you to use the default as long as you can. It can quickly become difficult to manage all of this.

Use Case:

We will create two namespaces “my-project-dev” and “my-project-prod” and two users “jean” and “sarah” with different roles to those namespaces:

  • my-project-dev:
    • jean: Edit
  • my-project-prod:
    • jean: View
    • sarah: Edit

Users creation and authentication with X.509 client certificates

We mainly have two types of users: service accounts managed by Kubernetes and normal users. We will focus on normal users. Here is how the official documentation describes a normal user:

Normal users are assumed to be managed by an outside, independent service. An admin distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords. In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call.

They are multiple ways of managing normal users:

  • Basic Authentication:
    • Pass a configuration with content like the following to API Server
      • <password>,<username>,<uid>,<group>
  • X.509 client certificate
    • Create a user’s private key and a certificate signing request
    • Get it certified by a CA (Kubernetes CA) to have the user’s certificate
  • Bearer Tokens (JSON Web Tokens)
    • OpenID Connect
      • On top of OAuth 2.0
    • Webhooks

For the purpose of this article we will use X.509 client certificates with OpenSSL for their simplicity. There are different steps for users creation. We will go step by step. You have to perform the actions as a user with cluster-admin credentials. These are the steps for user creation (here for “jean”):

  • Create a user on the master machine then go into its home directory to perform the remaining steps.
  • Create a private key:
  • Create a certificate signing request (CSR). CN is the username and O the group. We can set permissions by group, which can simplify management if we have, for example, multiple users with the same authorizations.
  • Sign the CSR with the Kubernetes CA. We have to use the CA cert and key which are normally in /etc/kubernetes/pki. Our certificate will be valid for 500 days.
  • Create a “.certs” directory where we are going to store the user public and private key.
  • Create the user inside Kubernetes.
  • Create a context for the user.
  • Edit the user config file. The config file has the information needed for the authentication to the cluster. You can use the cluster admin config which is normally in /etc/kubernetes. The “certificate-authority-data” and “server” variables have to be as in the cluster admin config.

    Then we need to copy the config above in the .kube directory.
  • Now we need to grant all the created files and directories to the user:

Now we have a user “jean” created. We will do the same for user “sarah”. There are many steps to perform and it can be very time consuming to do if we have multiple users to create. This is why I edit bash scripts which automate the process. You can find them on my Github repository.

Now we have our users, we can create the two namespaces :

As we have not defined any authorization to the users, they should get forbidden access to all cluster resources.

  • User: Jean

  • User: Sarah

Create Role and ClusterRole

We will use the default ClusterRole available. However we will show you how to create specific Role/ClusterRole. A Role/ClusterRole are just a list of verbs (actions) permitted on specific resources and namespaces. Here is an example of a YAML file:

To create them :

Bind Role or ClusterRole to Users

We are now going to bind default ClusterRole (Edit and View) to our users as below:

  • jean :
  • sarah :

We need to create RoleBinding by namespaces and not by user. It means that for our user “jean” we need to create two RoleBinding for his authorizations. Example of RoleBinding yaml file for Jean:

We assign to “jean” the view Role on “my-project-prod” and the edit Role on “my-project-dev”. We will do the same for “sarah” authorizations. To create them:

We have used kubectl apply here instead of kubectl create. The difference between “apply” and “create” is that “create” will create the object if it doesn’t exist and do nothing else. But if we “apply” a yaml file it means that it will create the object if it doesn’t exist and update it if needed.

Let’s check if our users have the right permissions.

  • User : sarah (Edit on “my-project-prod”)

Manage users and theirs authorizations

Now that we have set different roles and authorizations to our users, how can we manage all of this? How can we know if a user has the right access? How to know who can actually perform a specific action? How to have an overview of all the users access? These are the questions we need to answer to ensure cluster security. In Kubernetes we have the command kubectl auth can-i that allows us to know if a user can perform a specific action.

This first command allows a user to know if he can perform an action. The second command allows an administrator to impersonate a user to know if the targeted user can perform an action. The impersonation can only be used by a user with cluster-admin credentials. Apart from that, we can’t do much more. This is why we will introduce you some open-source projects that allows us to extend the functionalities covered by the kubectl auth can-i command. Before introducing them, we will install some of their dependencies such as Krew and GO.

Installation of GO

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. Inspired by C and Pascal, this language was developed by Google from an initial concept of Robert Griesemer, Rob Pike and Ken Thompson.

Installation of KREW

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Krew is only compatible with kubectl v1.12 and above.


This project helps us to know all the authorizations that have been granted to a user. It helps to answer to the question: what can do “jean” ? Firstly, let’s install Rakkess:

You can find the documentation on the project Github repository. Here is an example :


This project allows us to know who are the users who can perform a specific action. It helps to answer the question: who can do this action? Installation:

You can find the documentation on the project Github repository. Here is an example:


This project permits us to have a RBAC overview. It helps to answer the questions: Which Role has “jean” ? “sarah”? All the users? all the group? To install the project:

The official documentation is available on the project Github repository. An example:

RBAC Manager

This project allows us to have a manager for RBAC, as its name suggests. It simplifies many manipulations. The most important one is RoleBindings creation. Indeed we saw that if we needed to create different Roles for a user we needed to create different RoleBindings. RBAC Manager helps us by allowing us to create just one RoleBinding with all the authorizations inside. To install it, you can download the YAML file from the Github repository:

The official documentation is available on the project Github repository. An example:


We have created users inside Kubernetes cluster using X.509 client certificate with OpenSSL and granting them authorizations. You can use the script available on my Github repository in order to create users easily. As for the cluster administration, you can use the open-source projects that have been introduced in this article. To sum up those projects:

It can be very time consuming to handle all the steps about user creation. Especially if we have multiple users to create at once and others to create frequently. It could be easier if an enterprise LDAP is connected to Kubernetes cluster. There are open-source projects that provide a direct LDAP authentication webhook for Kubernetes: Kismatic and ObjectifLibre. Another solution is to configure an OpenId server with your enterprise LDAP for its backend.