Securing Your Kubernetes Cluster with RBAC

What is Kubernetes RBAC?

If your Kubernetes journey started with a small cluster of a few team members and a few nodes, you probably granted admin privileges to everyone in your team to simplify management. However, not all users need unlimited rights to create, modify, and delete resources, and giving everyone admin access can create serious security issues.

As the number of cluster nodes, applications, and team members grow, you need to limit the resources that team members and applications can access and the actions they can perform. This can be achieved with the Kubernetes role-based access control (RBAC) framework.

Using Kubernetes RBAC, certain individuals or teams can receive access only to certain applications in certain namespaces, while others might have only view-only access to monitoring tasks. You can provide granular access to each team member to the specific clusters, namespaces, and resources they need to do their job, in line with the principle of least privilege.

## Why Does RBAC Matter?

The RBAC mechanism provides fine-grained control over user rights to software applications. You can avoid over-privileged accounts and accurately assign capabilities to the individuals who need them.

Giving users too many features puts their credentials at risk of being lost or stolen. For example, developers should not be able to delete production deployments. Even if you implicitly trust your employees, which is not advisable given the risk of insider threats, phishing and social engineering attacks can allow outsiders to take control of their accounts. RBAC in Kubernetes allows you to create policies that prevent users from performing sensitive operations if they don’t need to.

At the application level, you can only use RBAC if the application is designed to support it. Each logical function must be supported by its own role. You can then assign users the roles appropriate to their responsibilities, in order to give them the desired set of permissions.

## Kubernetes RBAC Example

RBAC restricts and allows user roles with specific or groups of resources. See the following example to learn how to define a Role and RoleBinding with a service account for accessing the TEST namespace:


apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: AdminTestCase

namespace: TEST

rules:

resources: ['*']

verbs: [“get”, “list”, “watch”, “create”]

apiGroups: ['*']

  

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: AdminBindingTest # Creating RoleBinding

namespace: TEST

subjects:

- kind: ServiceAccount

name: mytestaccount

namespace: TEST

roleRef:

kind: Role # creating a role

name: AdminTest # Name of Role or Cluster role that is being bound

# is to be provided here

apiGroup: rbac.authorization.k8s.io

To deploy the test case for the Role and RoleBinding created above, use the following commands:


role.rbac.authorization.k8s.io/AdminTestCase created

  

rolebinding.rbac.authorization.k8s.io/AdminBindingTest created

The created Role provides authorization to access resources that have been made available to the service account through the AdminBindingTest RoleBinding.

Here is how to test the functionality by impersonating a service account:


kubectl auth can-i get pods -n TEST

--as=system:serviceaccount:TEST:mytestaccount

In this command:

  • auth can-i queries the request based access model

  • --as=system:serviceaccount:test:mytestaccountsimulates the mytestaccoun service account.

  • --as= requires extra parameters to identify the Service Account.

For example, for namespace default and Service Account named myserviceacc, you can use the following command:

General structure:

--as=system:serviceaccount:{namespace }:{service-account-name}

Example:

--as=system:serviceaccount:{default}:{myserviceacc}

Kubernetes RBAC Best Practices

Cluster Administrator Roles

Kubernetes includes a built-in cluster-admin role that grants unlimited access to the cluster. The transition from ABAC to RBAC might have replicated ABAC’s permissive configuration by granting cluster-admin widely to some users and service accounts.

However, if users or groups routinely get cluster-admin, the scope of damage inflicted by potential account compromises or mistakes increases. Most service accounts do not need this level of access. You should create a tailored role or cluster role and grant it to specific users who require it.

Least Privilege

The least privileges principles can help you assign minimal rights to each user and service account. It involves determining which rights a user needs to perform their role and assigning only the bare minimum, allowing only permissions explicitly required for an operation. Here are common best practices for Kubernetes:

  • Assign permissions at the namespace level—prefer RoleBindings over ClusterRoleBindings when assigning rights to users within a certain namespace.

  • Avoid wildcard permissions—When you provide wildcard access, Kubernetes gives rights to all object types currently existing in the cluster and to all future object types. Avoid these permissions to restrict access.

  • Use cluster-admin accounts—assign impersonation rights to a low-privileged account to avoid accidental modification of cluster resources.

  • Do not add users to the system:masters group—users in this group can bypass all RBAC rights checks and always get unrestricted superuser access. You cannot revoke it by removing ClusterRoleBindings or RoleBindings. A cluster using an authorization webhook can also bypass this webhook.

Minimize Distribution of Privileged Tokens

Do not assign pods with service accounts that have powerful permissions. Here are practices to help you minimize powerful permissions:

  • Limit the number of nodes that can run powerful pods—make sure you run only the necessary DaemonSets with least privileges to minimize the blast radius of container escapes.

  • Do not run powerful pods alongside publicly-exposed or untrusted pods—you can do this by using NodeAffinity, PodAntiAffinity, or taints and toleration. Monitor less-trustworthy pods that do not meet the restricted pod security standard.

Duplicated Role Grant

Role definitions can overlap, giving subjects the same access. While sometimes overlap is by design, this configuration makes it difficult to determine which subjects get each access right. It can also make access revocation difficult when you do not know that multiple role bindings are granting the same privileges.

Unused Role

Unused roles were created at some point but were not actually granted to subjects. This issue can make RBAC management more complicated. Additionally, roles that were granted to subjects that no longer exist, like users who have left the organization, also make it difficult to manage access rights. Strive to remove all unused and inactive roles to ensure you focus on active roles that truly require monitoring.

Conclusion

In this article, I explained the basics of RBAC and shared best practices how you can secure your Kubernetes cluster with it:

  • Cluster administrator roles—Kubernetes includes a built-in cluster-admin role that grants unlimited access to the cluster.

  • Least privilege—The least privileges principles can help you assign minimal rights to each user and service account.

  • Minimize distribution of privileged tokens—Do not assign pods with service accounts that have powerful permissions.

  • Duplicated role grant—Make sure role definitions don’t overlap.

  • Unused role—Strive to remove all unused and inactive roles to ensure you focus on active roles that truly require monitoring.

I hope this will be useful as you secure your Kubernetes cluster with RBAC.