Kubernetes RBAC: Basics and Advanced Patterns

Harshit Mehndiratta

October 27, 2021

9 Minute Read

This is some text inside of a div block.

Get Started Now

Kubernetes RBAC Series

Part 1: Introduction to Kubernetes RBAC
Part 2: Understanding Kubernetes RBAC Components
Part 3: The Complexity of Kubernetes RBAC
Part 4: Top Reasons and the Impact of Kubernetes RBAC Complexity
Part 5: Best Practices for Simplifying Kubernetes RBAC

Kubernetes has modernized how organizations build, test, and deploy their software. Thanks to its modularity, open-source framework, and Kubernetes RBAC, companies can create highly scalable and reliable enterprise-grade clusters while meeting strict security and governance requirements.

The Kubernetes RBAC framework implements access controls for different members, ensuring every user has the appropriate access to Kubernetes resources based on their responsibilities.

While RBAC management comes built into Kubernetes, its implementation can be tricky and confusing. This article will cover the basics of Kubernetes RBAC, how it works, and how it can be implemented within a Kubernetes cluster to enhance Kubernetes security.

Main Points

Kubernetes RBAC enables fine-grained access control for users and applications, ensuring that each subject has the appropriate permissions based on their role.
Default roles like cluster-admin, admin, edit, and view help users get started with Kubernetes RBAC but can be customized for more granular control.
Implementing Kubernetes RBAC involves creating roles and role bindings that define which resources a user or service account can access.
Regularly reviewing RBAC configurations and integrating with tools like Azure AD or Loft ensures compliance and strengthens Kubernetes security.

What Is Kubernetes RBAC?

Kubernetes RBAC is an authorization mechanism that enables fine-grained access control for users and applications interacting with Kubernetes resources in a cluster. There are several ways to manage Kubernetes authorization requests, such as attribute-based access control (ABAC) or webhooks, but RBAC is mainly used for production-grade deployments.

With Kubernetes RBAC, cluster admins can specify application access, add or remove permissions, and limit Kubernetes resource visibility based on roles. Permissions are granted to a user through manual declarations, which are stored and managed as Kubernetes RBAC roles. A role defines what actions a user or process can take on specific resources in the cluster, ensuring unauthorized access is minimized.

A role can represent a set of permissions on certain API objects like pods, nodes, and deployments. It uses the rbac.authorization.k8s.io API group, which determines Kubernetes API server authorizations and simplifies authentication. The Kubernetes API server dynamically configures policies, enabling quick adaptation to evolving rbac configurations.

How Does RBAC Work?

There are three major elements involved in RBAC:

1. Subjects

Subjects Clients, processes, and users call the Kubernetes API server to perform operations on cluster objects. They are categorized as users, groups, and service accounts. Users and Groups are not stored in the Kubernetes resource database and are meant for processes outside the cluster, often integrating with Azure AD or other identity providers.

ServiceAccounts: These exist as Kubernetes resource API objects and are used for intra-cluster processes such as interacting with a Kubernetes deployment or a service mesh.
ServiceAccounts: These exist as Kubernetes resource API objects and are used for intra-cluster processes such as interacting with a Kubernetes deployment or a service mesh.

2. Verbs

The operations executed on available Deployments, Services, and Pods in a Kubernetes cluster are called verbs. Examples are Create, Read, Update, or Delete (CRUD) operations. The verbs are sent to the API via HTTP, which Kubernetes translates based on the REST API URL.

3. Resources

These are the available Kubernetes resources ( API objects) like deployments, services, and persistent volumes. RBAC policies define roles that determine which specific resources a subject can interact with. Rules on these API objects are expressed as ClusterRoles/Roles that can be defined as Kubernetes subjects (users, groups, or service accounts) through RoleBinding and ClusterRoleBinding.

This ensures container security and reduces the risk of unauthorized access to sensitive data or critical infrastructure.

A role is a set of permissions that can be used across different subjects. Roles are usually bound to one namespace but can be used to represent more than one through wildcards.

Default Roles in Kubernetes

While Kubernetes allows for custom roles, there are default roles that come with every AKS cluster or Google Kubernetes Engine setup:

Cluster-admin: Provides super-user access to perform actions on any Kubernetes resource cluster-wide.
Admin: Grants full permissions within a namespace.
Edit: Allows permissions to edit objects within a namespace.
View: Grants read-only access to view objects in a namespace.

These default roles help you get started with rbac management, but most production environments require more granular control. Roles can be customized and configured to manage Kubernetes security more effectively by limiting access to specific resources across the cluster.

These are the different sets of permissions:

ClusterRole: this is a role object applied cluster-wide. Granting a user a ClusterRole provides view and edit access across all the namespaces, resource quotas, and nodes of the cluster.
RoleBinding: a RoleBinding binds API objects and operations that can be executed on them by subjects. It also handles operations for a particular namespace.
ClusterRoleBinding: a ClusterRoleBinding manages operations executions by subjects across the entire cluster.

Implementing RBAC in a Kubernetes Cluster

Here’s a step-by-step guide to implementing basic Kubernetes RBAC in your cluster. These steps can be applied to any Kubernetes cluster, whether you’re using Azure Kubernetes Service, Google Kubernetes Engine, or a self-hosted Kubernetes setup.

These steps have been tested in minikube, but they can be applied to any Kubernetes cluster.

Here is what you need to begin:

Kubernetes cluster running
Kubernetes CLI kubectl installed
Basic understanding of Kubernetes pods, namespaces, and service accounts
A client certificate (CRT) and private key generated using OpenSSL

Creating a User

Kubernetes can authenticate users with client certificates (CRT), but it does not provide an API for user creation. To configure access, you need to create a user entry with kubectl auth by generating a client certificate ((.crt) and private key(.key) using OpenSSL.

This method integrates well with Azure AD and other identity management solutions for seamless rbac configuration. Once you have the .key and the .crt files, we can set a user entry in kubeconfig using this command:

kubectl config set-credentials user1 --client-certificate=user1.crt --client-key=user1.key

In the above command, we are setting the user named user1.

Response:

You should see that the user is set for access in the Kubernetes cluster:

User "user1" set.

Set a context element for the created user to check its access privileges for a Kubernetes cluster. To set a context entry in kubeconfig, use this command:

kubectl config set-context user1-context --cluster=minikube --user=user1

Response:

Context "user1-context" created.

Switch to user1-context using this command:

kubectl config use-context user1-context

Now you can check permissions for user1 and create roles to provide resource access.

Creating a Service Account

Service accounts in Kubernetes are used for identity authentication and authorization by pods. Pods are assigned automatically to the “default” service account in your Kubernetes cluster, and applications share this account.

Use the following command to create a service account:

kubectl create serviceaccount podreader

Response:

serviceaccount/pod-reader created

You can also list other ServiceAccount resources in the namespace with the command:

kubectl get serviceaccounts

Response:

NAME SECRETS AGE admin 1 5h25m default 1 6h13m pod-reader 1 5m35s

Creating a Role

A role object configuration file in Kubernetes defines what you can do to users, groups, or service accounts. The configuration is expressed as a YAML file and has a particular schema:

kind: apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: name: rules: apiGroups: [""] resources: [] verbs: []

kind: this specifies the kind of role. It can be of two types—role or cluster role. A role will typically provide access to resources bound to one namespace, while the cluster role provides access to resources across the cluster.

namespace: this specifies the namespace to which a role is bound. With ClusterRoles, the namespace variable is omitted since ClusterRoles are not namespaced.

name: this is the name of the role.

apiGroups: this indicates the core API groups used.

resources: these are the resources that a user wants to access. Examples include pods, deployments, services, namespaces, or ConfigMaps.

verbs: these are actions that a subject can execute on resources, including list, delete, create, watch, update, or edit.

To create a role, specify the configuration in the YAML file. Here is a sample role configuration for allowing the particular user to list pods.

#role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: get-pods rules: apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]

To match the user to the above role, use get-pods.

Next, create a RoleBinding.

Creating a RoleBinding

A RoleBinding object configuration file would look similar to this:

#rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "user1" to read pods in the "default" namespace. kind: RoleBinding metadata: name: user-get-pods namespace: default subjects: kind: User # Here ServiceAccounts can also be specified instead of user name: user1 # "name" is case sensitive. Specify the name of the user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role #this must be Role or ClusterRole name: get-pods # this must match the name of the Role you wish to bind to apiGroup: rbac.authorization.k8s.io

Apply the RBAC Settings

Create the RBAC role by using the following command:

kubectl create -f <PATH to Role.yaml file>

Create the RBAC role binding by using the following command:

kubectl create -f <PATH to role-binding yaml file>

Note that if role and RoleBindings are implemented correctly, subjects will be able to perform specified operations on cluster objects.

Take Control of Your Kubernetes Security with Loft

Managing Kubernetes RBAC is essential for controlling access to your Kubernetes resources, but the process can be complex and time-consuming. Loft simplifies RBAC management by automating RBAC policies, ensuring compliance, and integrating seamlessly with tools like Azure AD.

With Loft, you can prevent unauthorized access and maintain strong Kubernetes security. Don’t leave your clusters vulnerable—whether you're using AKS, Google Kubernetes Engine, or any Kubernetes environment, mastering Kubernetes RBAC with Loft ensures the highest level of security and resilience for your infrastructure. To learn more, have a look at the docs or schedule a personalized demo.

Photo by Rob King on Unsplash