Access Control is a standard way to management the security of any system. Kubernetes is not left out in this philosophy. k8s has a solid access control system that it uses to manage granular access to its API resources and services.
The access control feature in Kubernetes is granular enough to manage read and write operations across all resources running in the Kubernetes cluster and gives the cluster administrator the authority to manage access based on scope and requirements.
This feature in Kubernetes is called RBAC (pronounced r-Back), which is an acronym for Role-based Access Control. What is RBAC in Kubernetes
What is RBAC in Kubernetes ?
Role-Based Access Control (RBAC) in Kubernetes is a security system that controls who can access and manage cluster resources. It works by assigning specific permissions to users, groups, or service accounts based on predefined roles. This ensures that only authorized users can perform actions like creating, reading, updating, or deleting resources such as pods and services. RBAC helps improve security by limiting access to only what is necessary, reducing the risk of unauthorized changes in a shared Kubernetes environment.
Components of RBAC in Kubernetes
RBAC in Kubernetes consists of four primary components:
Role
- A Role defines a set of permissions (rules) within a specific namespace. It specifies which actions (verbs) can be performed on which resources.
- Example actions include: get, list, watch, create, update, delete for resources like pods, configmaps, secrets, etc.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
– apiGroups: [“”]
resources: [“pods”]
verbs: [“get”, “watch”, “list”]
ClusterRole
- Similar to a Role but applies cluster-wide rather than being restricted to a single namespace.
- Used to grant permissions that affect the entire cluster, such as access to nodes or persistent volumes.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-viewer
rules:
– apiGroups: [“”]
resources: [“nodes”]
verbs: [“get”, “watch”, “list”]
RoleBinding
- A RoleBinding associates a Role with a user, group, or service account within a namespace, granting them the specified permissions.
- It ensures that only authorized entities can interact with the namespace’s resources.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
– kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
- Works like a RoleBinding but links a ClusterRole to users, groups, or service accounts globally, giving them permissions across all namespaces.
- Used for cluster-wide permissions, such as allowing administrators to manage all workloads.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-nodes
subjects:
– kind: User
name: admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: node-viewer
apiGroup: rbac.authorization.k8s.io
There are other essential configuration parameters that are used in the Roles and RoleBindings they are:
Subjects: Defines who/what assumes the permission
- Users: External entities (e.g., individuals) authenticated by the cluster.
- Groups: Collections of users (e.g., developers, admins).
- ServiceAccounts: Internal Kubernetes accounts used by applications or pods to interact with the API server.
Rules: Defines the permissions for a Role or ClusterRole
- apiGroups: The API group (e.g., “” for core resources, apps for deployments).
- resources: The resource type (e.g., pods, services).
- verbs: The actions allowed (e.g., get, list, create, delete).
How to Apply Read-Only Access to Pods for a User
Step 1: Create a Role
# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
– apiGroups: [“”]
resources: [“pods”]
verbs: [“get”, “watch”, “list”]
This role will allow read-only access to pods in the default namespace
Step 2: Create a RoleBinding
# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
– kind: User
name: ewere
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Bind the role to a user named ewere
Step 3: Apply the Role
kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml
Step 4: Verify Access
kubectl auth can-i create pods –namespace=default –as=ewere
RBAC Best Practices
Least Privileges Practices
When configuring RBAC (Role-Based Access Control) in Kubernetes, the goal should always be to grant the least privilege necessary. Over-permissioning can lead to security risks and accidental misconfigurations. Start by assigning permissions at the namespace level whenever possible, using RoleBindings instead of ClusterRoleBindings to keep access limited to specific namespaces rather than the entire cluster. This helps prevent users and service accounts from gaining unnecessary access to sensitive resources across different projects or teams.
Avoid using wildcard permissions, especially those that apply to all resources. Kubernetes is an extensible system, meaning new object types can be introduced at any time. If wildcard permissions are granted, they will apply not only to existing resources but also to any future ones, potentially opening up unintended security gaps.
Administrators should limit their use of cluster-admin accounts and instead operate with lower-privileged accounts whenever possible. If elevated permissions are required for specific tasks, using impersonation rights allows for temporary privilege escalation without exposing critical system-level access. This approach reduces the chances of accidental modifications to core cluster resources, improving both security and stability.
One of the most critical best practices is to avoid adding users to the system:masters group. Anyone in this group effectively bypasses all RBAC restrictions, making it impossible to enforce access control policies through RoleBindings or ClusterRoleBindings. Additionally, if the cluster uses an authorization webhook for fine-grained access control, users in the system:masters group will completely bypass that webhook, meaning their requests won’t even be evaluated for compliance.
By following these principles—scoping permissions properly, avoiding broad access, and minimizing reliance on privileged accounts—teams can maintain a more secure and well-governed Kubernetes environment, reducing both operational risks and potential security vulnerabilities.
Privilege Token Restriction
When deploying workloads in Kubernetes, it’s crucial to ensure that pods are not assigned service accounts with excessive permissions, especially those that could lead to privilege escalation risks. If a specific workload does require elevated privileges, several best practices should be followed to minimize security risks.
First, limit the number of nodes that can run high-privilege pods. This helps contain potential security breaches by reducing the surface area for exploits. If DaemonSets need to run on nodes, ensure they are absolutely necessary and operate with the principle of least privilege, restricting their permissions to only what is required. This approach helps minimize the impact in case of a container escape or an unauthorized privilege escalation attempt.
Second, avoid scheduling privileged workloads alongside untrusted or publicly exposed pods. Keeping high-privilege workloads isolated reduces the risk of a compromised pod escalating privileges or affecting more critical applications. Kubernetes provides multiple mechanisms to enforce this separation, such as Taints and Tolerations, which prevent untrusted workloads from being scheduled on nodes designated for high-privilege workloads. Node Affinity can be used to ensure that specific workloads only run on pre-approved nodes, while Pod Anti-Affinity ensures that sensitive workloads are not placed on the same node as potentially risky ones.
Lastly, it’s essential to enforce security standards like the Restricted Pod Security Standard to prevent lower-trust pods from bypassing critical security policies. If pods fail to meet these security standards, they should not be allowed to run on the same nodes as high-privilege workloads. By implementing these security measures, you can reduce the risk of privilege escalation and ensure that Kubernetes clusters remain resilient against potential threats.
Hardening and Periodic Review
Kubernetes provides some default access permissions that might not be necessary for every cluster. Reviewing these default RBAC (Role-Based Access Control) settings can help improve security. While system accounts (like system: accounts) should generally be left unchanged, there are a few steps you can take to strengthen access controls:
- Check system:unauthenticated bindings – This group allows anyone who can reach the API server to have access. If possible, remove these bindings to prevent unauthorized access.
- Disable automatic service account token mounting – By default, Kubernetes automatically provides service account tokens to pods, which may not always be needed. You can disable this by setting automountServiceAccountToken: false in your pod definitions. If a workload does require a service account token, it can still be manually mounted.
Taking these steps helps reduce unnecessary exposure and improves the overall security of your Kubernetes cluster. Regularly reviewing Kubernetes RBAC settings is essential to identify redundant permissions and potential security risks. One major concern is that if a deleted user’s account is recreated with the same name, it could automatically regain all previously assigned permissions, including any elevated privileges. This could be exploited by an attacker to gain unauthorized access.
Conclusion
In this article the concept of RBAC in Kubernetes was introduced and the different components that make up the RBAC architecture and how they all tie-together to implement fine-grained access control to Kubernetes resources and services. RBAC is an industry standard approach that should be applied to managing user and service account access in Kubernetes most especially in a non-Cloud environment setup where there is no addition layer of security like IAM in AWS that can implement some-level of security. Understanding RBAC in k8s is key to ensuring the cluster is always secured from malicious access and activities
