How to use Kubernetes RBAC

Role-based access control (RBAC) is a security methodology that restricts user interactions to specifically allocated features. User accounts are granted roles; those roles permit access to distinct capabilities of the software.

In the context of Kubernetes, RBAC lets you limit what individual users can change inside your cluster. You can restrict sensitive operations to the people that really need them, reducing your attack surface in case an account is compromised.

In this article, you’ll learn how to set up a simple RBAC implementation inside your Kubernetes cluster. You’ll also cover some best practices for managing RBAC policies, so you can enforce strong security and protect your applications.

Why does RBAC matter?

RBAC mechanisms offer granular control of user permissions in software applications. You can precisely allocate features to the individuals that need them, avoiding over-privileged accounts.

Giving users too many capabilities poses a risk if credentials are lost or stolen. As an example, developers probably shouldn’t be able to delete your production deployments. Even if you trust your employees implicitly, a phishing or social engineering attack could give people outside of the company control of the overpowered account. With RBAC in Kubernetes, you can create a policy that prevents users from deleting pods.

RBAC only works when the application is designed to support it. Each logical capability should be backed by its own role. You can then assign users the roles that make sense for their responsibilities, mixing and matching to obtain the desired set of privileges.

Using RBAC with Kubernetes

Kubernetes has extensive support for RBAC. It permeates the system’s architecture and supports role delineation by resource and verb. For example, each of the following actions can be expressed as distinct RBAC rules:

• Listing pods
• Creating a pod
• Viewing the data inside secrets
• Deleting a deployment
• Adding more users

Rules are combined into roles that cover multiple actions. The rules shown above could be used to create a developer role that’s able to list and create pods, and a separate administrator role that can list and create pods, but is also able to initiate deletions and manage users. You have fine-grained control over the capabilities available to each user.

Four fundamental objects scaffold the Kubernetes RBAC implementation:

• Role: A collection of one or more rules defining the actions that users can take.
• RoleBinding: An association between a role and one or more users or service accounts, called subjects. Each subject targeted by the binding can perform the actions covered by the role.
• ClusterRole and ClusterRoleBinding: These are variants of Role and RoleBinding that exist at the cluster level. They’re used to create rules that target cluster-level resources such as nodes.

Now let’s see how to use these objects to set up RBAC in your own Kubernetes cluster.

Implementing RBAC in a Kubernetes cluster

Most new clusters will start you with a fully privileged user account that can perform any Kubernetes action. RBAC is an optional feature that can be turned off altogether. Run the following command to see if it’s enabled:

The command above has produced a line of output which shows RBAC is available. If you don’t see any output, that indicates that RBAC is turned off in your cluster. You can enable the feature by starting the Kubernetes API server with the RBAC authorization mode included:

You should refer to the documentation included with your Kubernetes distribution to get detailed guidance on starting the API server.

Manual RBAC enablement shouldn’t be necessary if you’re using a Kubernetes cluster deployed from a managed cloud service. RBAC is usually on by default for clusters provisioned by major providers.

Creating a test user

Next, you’ll create a test user account that you’ll assign your RBAC roles to. Kubernetes recognizes two types of user: a normal user and a service account. Normal users can’t be added using regular API calls, so we’ll create a service account for this tutorial. The Kubernetes documentation includes a description of the differences between the user types and explanations of when each one is appropriate.

Run the following command to add a new service account called demo:

Find the name of the secret that stores the service account’s token:

The secret’s name is demo-token-znwmb. Retrieve the token’s value from the secret using the following command:

With the token extracted, you can add your user as a new kubectl context:

If your current cluster connection is not called kubernetes, you should change the value of the --clusterflag.

Now you can switch to your demo context to run kubectl commands as your new service account user. Run the current-context command first to check the name of your currently selected context—you’ll be switching back to it in a moment.

Try to retrieve the pods in your cluster:

Kubernetes has issued a Forbidden error. The demo service account has been recognized, but because no roles have been created or assigned, it lacks permission to run the get pods command.

Creating a role

Switch back to your original context before continuing, so you regain your administrative privileges:

Kubernetes role objects are created in the standard way. You write a YAML file that defines the role’s rules, then use kubectl to add it to your cluster.

To keep things simple, you’ll use the “Developer” role example from earlier:

Users who are assigned this role will be able to run the create pod, get pod, get pods, and describe pod commands. They won’t be able to update or delete pods, or perform actions that target other resource types.

Use kubectl to add the role to your cluster:

Creating a roleBinding

A role on its own has no effect on your cluster’s access control. It needs to be bound to users with a RoleBinding. Create this object now to grant your demo service account the permissions associated with your Developer role:

The subjects field lists the objects that will be granted the permissions included in the role. In this example, you’re adding a single ServiceAccount subject to represent your demo user. You can target a User or Group instead by adjusting the subject’s Kind accordingly.

The roleRef field identifies the role that will be bound to the subjects. The kind can be either Role or ClusterRole, depending on the type of role you’ve created. In this example, the Developer role is a regular role.

Add the RoleBinding to your cluster using kubectl:

Testing the RBAC policy

The RoleBinding should have granted your demo service account the permissions included in the Developer role. Verify this by switching back to your demo context:

Repeat the get pods command:

This time the command succeeds. The get pods operation is permitted by the Developer role, which is now assigned to the demo service account you’re authenticated as.

Create a new pod:

This operation is permitted, too. Now, try to delete the superfluous pod:

Kubernetes rejects the operation because the demo service account doesn’t have a role that provides a suitable permission. This demonstrates how you can use Role and RoleBinding objects to restrict how users interact with your cluster.

Kubernetes RBAC best practices

As we’ve seen above, a basic Kubernetes RBAC implementation is simple to set up. However, it’s important to adhere to some best practices for maximum effectiveness and security.

• Avoid over-privileged roles: Role creation is a balancing act. On the one hand, a large number of roles with a handful of permissions each are hard to manage and assign. However, roles that include permissions because of a vague “might be needed one day” mindset can be a security weakness. Target your roles to specific use cases, and don’t be afraid to add a new one if it seems to be the best option.
• Regularly review your RBAC roles: RBAC policies need to be regularly audited, so you remain aware of who can do what inside your cluster. RBAC strengthens your security, but forgotten or unnecessary role assignments can mask lurking threats.
• Be careful with wildcards: Roles let you use wildcards like * in their resources and verbs fields. This can be a tempting shortcut, but it makes it harder to effectively audit and maintain your policies. It also opens the possibility that users could receive automatic access to new resources added in future Kubernetes releases.
• Don’t forget users and service accounts: Authentication is important, too. There’s little point in using RBAC if the same account is reused across multiple services and individuals. Set up a dedicated service account for each integration, then assign it the individual roles it needs.
• Remove unused roles: Unused roles and RoleBindings can clutter your cluster and cause confusion. Only create roles that are needed in your workflows and processes. Too many redundant roles will make it difficult to understand how capabilities are being distributed throughout your cluster.

Keeping these best practices in mind will help you set up a secure Kubernetes environment that makes good use of granular RBAC policies. Give each user the minimum level of privileges they require, then review each role regularly to ensure the level of access remains appropriate.

Final thoughts

Role-based access control (RBAC) is a feature-driven method of permissions enforcement. It decouples actions from the users capable of performing them, letting you create unique policies that match each individual’s responsibilities. Within Kubernetes, you can create precise RBAC rules for each verb and resource combination in your cluster. A developer role might permit only “create pods,” list pods," and “view logs,” reducing the risks associated with an account compromise. Once you’ve created your roles, you can associate them with users via RoleBinding objects.

While RBAC is a powerful security tool, it’s only one part of safe and secure Kubernetes management. You also need effective monitoring procedures so you can track activity in your cluster and spot potential issues.

If you're looking for a powerful internal tooling platform that makes it easy to set permissions securely based on the sensitivity of your operations, then check out Airplane. Airplane is the developer platform for building custom workflows and UIs. With Airplane, you can build admin panels, database management dashboards, and more. Airplane offers strong out-of-the-box capabilities including permissions setting that makes it easy and secure to set granular permissions by team or individual.

If you'd like to try it out and build your first workflow with specific permissions, sign up for a free account or book a demo.