RBAC, Service Accounts, and IAM solve the problem of controlling exactly who or what can access your Kubernetes cluster and what actions they can perform. For the Certified Kubernetes Security Specialist (CKS) exam, understanding these concepts is essential because they are the primary way you enforce security boundaries inside a cluster. Mastering them is not optional — it is the difference between a secure cluster and one that is wide open to attackers.
Jump to a section
A simple way to picture RBAC, Service Accounts, and IAM
A building security pass system controls who can enter which rooms and when.
Think of a large office building with many different areas: a ground-floor lobby, a second-floor finance department, a third-floor IT server room, and a fourth-floor executive suite. Each employee receives a security pass that grants access only to the specific areas they need for their job. A cleaner, for instance, has a pass that opens the lobby and common areas but not the server room. The finance team lead has a pass that opens the finance department and the executive suite for meetings. This pass is like an 'identity' — it proves who you are and what you are allowed to do.
Now imagine a visitor arrives. They don't get a personal pass; instead, they are issued a temporary guest pass at the front desk. This guest pass has very limited permissions — it might only open the lobby and a specific meeting room for one day. This is like a 'service account' in IT: a special identity used by an application or a machine, not a human, with just enough access to perform its task. The building manager (the 'administrator') is the only person who can create, modify, or revoke these passes. They decide the rules: who gets which pass, what each pass can open, and when a pass expires. This entire system is 'role-based access control' (RBAC) — access is granted based on a person's role (cleaner, finance lead, visitor) rather than their individual name.
Role-Based Access Control (RBAC) is a method of regulating access to a computer system based on the roles of individual users within an organisation. In Kubernetes, RBAC is the built-in mechanism for controlling who (or what) can do what inside your cluster. It replaces older, less flexible systems where every user was either an all-powerful administrator or had no access at all. RBAC allows you to define fine-grained permissions, so a developer can deploy an application but cannot delete a node, while a security auditor can view logs but cannot change any settings.
Before RBAC, many systems used 'Access Control Lists' (ACLs), which were lists of users and their permissions attached directly to each resource. This became unmanageable as the number of users and resources grew — you would have to edit every resource to add or remove a user. RBAC solves this by introducing three core components:
A 'Role' is a collection of permissions. For example, a Role called 'pod-reader' might allow listing, getting, and watching pods.
A 'Subject' is the entity that wants access. This can be a human user, a service account (an identity for an application), or a group of users.
A 'RoleBinding' links a Role to a Subject. It says: 'Subject X gets Role Y'. This is the rule itself.
These components exist within a 'Namespace', which is a way to partition a single Kubernetes cluster into multiple virtual clusters. For example, you might have separate namespaces for 'development', 'staging', and 'production', each with its own set of Roles and RoleBindings. This means a developer in the 'development' namespace cannot accidentally affect resources in 'production'.
Kubernetes also provides 'ClusterRole' and 'ClusterRoleBinding'. These are exactly like Role and RoleBinding, but they apply cluster-wide, not just within a single namespace. You use a ClusterRole when you need to grant permissions to resources that exist across all namespaces, such as nodes (the physical or virtual machines that run your workloads) or persistent volumes (storage that outlives a pod). For instance, a 'cluster-admin' ClusterRole grants full control over every resource in the entire cluster.
A 'Service Account' is a special type of Subject designed for use by applications or automated processes, not human users. When you run a pod, you can assign it a specific service account. The pod then uses the credentials of that service account to authenticate to the Kubernetes API server when it needs to perform actions like listing pods or creating deployments. A service account is like a robot that needs a keycard to do its job. By default, every namespace has a service account called 'default', and if you do not specify one, your pod will use that default service account, which often has minimal permissions. This is a common security pitfall.
'Identity and Access Management' (IAM) is the broader discipline that encompasses RBAC and service accounts, but in the Kubernetes context, it often refers to how you integrate with a cloud provider's IAM system, such as AWS IAM or Google Cloud IAM. For example, you can configure your Kubernetes cluster to allow users authenticated by AWS IAM to assume a specific Kubernetes role. This is called 'IAM integration'. It allows you to use your existing corporate identity system (like Microsoft Entra ID) to control access to the cluster, rather than managing separate Kubernetes users.
Why does this exist? Because without RBAC, every user and every application in your cluster would have unlimited power. A single compromised developer account or a buggy application could delete your entire production database. RBAC enforces the 'principle of least privilege' — every subject gets only the minimum permissions necessary to perform its function. For CKS, you must understand how to create, view, and test these RBAC rules, because the exam will ask you to identify misconfigurations and recommend fixes.
Check Current RBAC State
Run 'kubectl get rolebindings --all-namespaces' and 'kubectl get clusterrolebindings' to list all existing bindings. This gives you a baseline view of who can do what. You also run 'kubectl describe clusterrolebinding cluster-admin' to see exactly which subjects have full cluster control. This step is crucial for auditing and for forming a plan before making any changes.
Create a Service Account for an Application
Use a YAML file or 'kubectl create serviceaccount my-app-sa -n my-namespace' to create a dedicated service account. This separates the application's identity from human users and from the default service account. The application will use this identity to authenticate to the API server.
Define a Role with Minimal Permissions
Create a Role YAML that specifies exactly what the application needs. For example, if the app reads logs from pods, the Role might include rules for 'get' and 'list' on 'pods/log' resources. You define 'apiGroups' (like '' for core), 'resources' (like 'pods'), and 'verbs' (like 'get', 'list'). This Role lives in the same namespace as the service account.
Bind the Role to the Service Account
Create a RoleBinding that links the Role you just created to the service account. The RoleBinding's 'subjects' section specifies the service account's name and kind ('ServiceAccount'), and the 'roleRef' section points to the Role. This completes the permission grant. The application now has exactly the permissions you defined.
Test the Permissions Using Kubectl
Run 'kubectl auth can-i --as=system:serviceaccount:my-namespace:my-app-sa get pods' to simulate an action. The output 'yes' or 'no' confirms whether the permission is granted. Repeat for every action the application needs. This verifies your role is correct and catches over-permissioning before deployment.
Audit and Remove Unnecessary Bindings
Periodically run the initial commands again and compare the output. Look for any ClusterRoleBinding that grants 'cluster-admin' to a service account or to a user who no longer needs it. Delete the binding with 'kubectl delete clusterrolebinding my-binding'. This step ensures you are not accumulating excessive permissions over time.
An IT professional responsible for a Kubernetes cluster uses RBAC and service accounts every day to keep the system safe. Imagine you work for a company called 'FinSecure', which runs a financial trading platform on Kubernetes. The cluster has three namespaces: 'frontend' (the web application traders see), 'backend' (the order processing engine), and 'database' (the PostgreSQL database).
One morning, a new developer, Priya, joins the frontend team. Your first task is to give her the correct access. You do not give her a 'cluster-admin' role — that would be like giving a new intern the keys to the entire building. Instead, you create a Role called 'frontend-dev' that allows her to create and update deployments and services only in the 'frontend' namespace. You then create a RoleBinding that links the 'frontend-dev' Role to Priya's username. This takes about five minutes. Later, when the backend team needs a service account for a script that checks the health of backend services, you create a service account called 'backend-health-checker'. You create a Role called 'backend-reader' that only allows listing pods and services in the 'backend' namespace, and bind that role to the 'backend-health-checker' service account. The script runs with exactly the permissions it needs — nothing more.
Now, imagine a production incident. A malicious actor compromises the backend service account and tries to delete all pods in the 'database' namespace. Because the service account only has read permissions in the 'backend' namespace, the attack fails. The RBAC rules you put in place blocked the action. You would investigate by running the command 'kubectl describe rolebinding' in the affected namespaces to see exactly what permissions each subject has. You might also use 'kubectl auth can-i --as=system:serviceaccount:backend:backend-health-checker --list' to simulate what that service account is allowed to do.
Another real-world task is auditing existing RBAC rules. At FinSecure, you run 'kubectl get rolebindings --all-namespaces' every week and review each binding. You look for 'ClusterRoleBinding's that grant 'cluster-admin' to too many users — this is the most common misconfiguration. You also check for service accounts that are bound to a 'cluster-admin' ClusterRole, which would give every pod using that service account full control of the cluster. You ensure that the default service account in each namespace has no permissions at all, forcing developers to explicitly create and assign service accounts to their pods.
Finally, you would integrate the cluster with Microsoft Entra ID. This means when Priya logs in with her corporate credentials, the cluster authenticates her via Microsoft Entra ID and maps her to a Kubernetes user. You then use RBAC to grant that user permissions. This single sign-on (SSO) approach eliminates the need to manage separate Kubernetes user passwords and makes it easy to revoke access when an employee leaves the company — just disable their Microsoft Entra ID account. This is the standard enterprise setup for any serious Kubernetes deployment.
The CKS exam tests RBAC and service accounts heavily because they are the foundation of Kubernetes security. You can expect multiple questions that ask you to examine a YAML manifest or a cluster state and identify an RBAC misconfiguration. The exam is practical — you will be given a terminal and a running cluster, and you must fix problems.
Key exam topics include:
Understanding the difference between a Role and a ClusterRole. A Role is namespace-scoped; a ClusterRole is cluster-scoped. The exam loves to test this: if a subject needs to access a resource that lives across namespaces (like nodes), you must use a ClusterRole. If it only needs access to pods in one namespace, use a Role.
Knowing the difference between a RoleBinding and a ClusterRoleBinding. A RoleBinding can reference either a Role (in the same namespace) or a ClusterRole (to grant that ClusterRole's permissions to a specific namespace). A ClusterRoleBinding grants cluster-wide permissions to a subject.
Creating a service account and binding it to a role. You will need to write YAML or use kubectl commands to create a service account, then create a Role and RoleBinding that grants that service account the necessary permissions.
Verifying permissions with 'kubectl auth can-i'. This is a command you must practise. The exam will ask you to check whether a specific user or service account can perform a specific action, like 'kubectl auth can-i create deployments --as=system:serviceaccount:default:my-sa'. You need to interpret the output correctly.
Common trap patterns include:
A ClusterRoleBinding that references a Role (which is invalid; ClusterRoleBindings always reference ClusterRoles).
A RoleBinding that references a Role from a different namespace (also invalid; RoleBindings must reference a Role in the same namespace or a ClusterRole).
The 'default' service account in a namespace being given too many permissions. The exam will present a cluster where the default service account has 'cluster-admin' permissions, and you must identify this as a major security risk.
Subjects (users, groups, service accounts) being incorrectly referenced in the 'subjects' section of a RoleBinding. For a service account, the correct format is 'kind: ServiceAccount' and 'name: my-sa'. For a user, it is 'kind: User' and 'name: username'.
Key definitions to memorise:
Role: a set of rules defining a set of permitted actions on a set of resources, scoped to a namespace.
ClusterRole: the same as a Role, but cluster-scoped (no namespace).
RoleBinding: grants a Role or ClusterRole to a subject within a namespace.
ClusterRoleBinding: grants a ClusterRole to a subject cluster-wide.
Service Account: an identity for a pod or a non-human process.
Subject: the entity receiving permissions (User, Group, or ServiceAccount).
'apiGroups': the API group of the resource (e.g., '' for core resources like pods; 'apps' for deployments).
'resources': the specific resource type (e.g., 'pods', 'services', 'deployments').
'verbs': the allowed actions (e.g., 'get', 'list', 'create', 'update', 'delete', 'watch').
The exam will also test your ability to read and write YAML for RBAC resources. You must be comfortable with the 'rules' section inside a Role or ClusterRole, including how to specify multiple rules for different resources. Practise writing YAML for scenarios like 'allow a service account to get and list pods in namespace X, but not delete them'. The CKS exam is not a multiple-choice test — you perform actions in a real cluster, so you must be able to create, edit, and delete RBAC resources using the kubectl command-line tool.
RBAC in Kubernetes grants permissions based on a subject's role, not their individual identity, following the principle of least privilege.
A Role is namespace-scoped, while a ClusterRole is cluster-scoped, and you bind them using RoleBinding (namespace-level) or ClusterRoleBinding (cluster-wide).
Service accounts are non-human identities for pods and applications, and each pod should have a dedicated service account with only the permissions it requires.
The default service account in every namespace should have its automatic mounting disabled to prevent unauthorised API access from any pod.
To verify permissions, use the 'kubectl auth can-i' command, which simulates an action and tells you if it is allowed or denied.
A RoleBinding can grant a ClusterRole's permissions to a specific namespace, but a ClusterRoleBinding always grants permissions across the entire cluster.
Integrating Kubernetes with an external IAM system like Microsoft Entra ID allows you to use your corporate identity for cluster authentication, simplifying user management.
Always audit ClusterRoleBindings for 'cluster-admin' — giving this role to too many subjects is the most common and dangerous misconfiguration.
These come up on the exam all the time. Here's how to tell them apart.
Role
Scoped to a single namespace.
Cannot grant permissions to cluster-scoped resources like nodes.
Created and exists within a namespace.
ClusterRole
Scoped to the entire cluster.
Can grant permissions to cluster-scoped and namespace-scoped resources.
Exists at the cluster level, not within a namespace.
RoleBinding
Grants permissions only within the namespace where it is created.
Can bind either a Role (same namespace) or a ClusterRole.
Created in a specific namespace.
ClusterRoleBinding
Grants permissions globally across all namespaces.
Can only bind a ClusterRole.
Exists at the cluster level, not in any namespace.
Service Account
Used by applications and automated processes.
Authenticates via a token that is mounted into a pod.
Managed within Kubernetes using kubectl or YAML.
User Account
Used by human operators.
Authenticates via certificates, passwords, or external identity provider.
Often managed outside Kubernetes through an IAM system like Microsoft Entra ID.
Verb 'get'
Retrieves details of a single resource by its name.
Example: 'kubectl get pod my-pod'.
Requires knowing the resource name.
Verb 'list'
Retrieves a collection of resources (e.g., all pods in a namespace).
Example: 'kubectl get pods'.
Does not require specifying individual resource names.
Mistake
A RoleBinding can bind a Role from any namespace.
Correct
A RoleBinding can only bind a Role that exists in the same namespace. To grant permissions from a Role in another namespace, you must use a ClusterRole bound with a RoleBinding.
This mistake happens because beginners think namespaces are just organisational labels that can be ignored when binding roles, but Kubernetes enforces namespace boundaries for RoleBindings.
Mistake
A service account and a user are the same thing and can be used interchangeably.
Correct
A service account is a non-human identity intended for applications and automated processes, while a user is a human. They are different kinds of subjects in Kubernetes. Using a user identity for an application creates security risks because human credentials can be lost or stolen.
The word 'account' in 'service account' misleads beginners into thinking it is just another type of user account, but Kubernetes treats them as entirely separate identity types with different authentication mechanisms.
Mistake
If you create a ClusterRole, you must use a ClusterRoleBinding to grant its permissions.
Correct
You can grant a ClusterRole's permissions to a specific namespace by using a RoleBinding that points to the ClusterRole. A ClusterRoleBinding grants those permissions cluster-wide. This is a crucial distinction.
The name 'ClusterRole' sounds like it can only be used cluster-wide, but Kubernetes allows you to reuse a ClusterRole at the namespace level via a RoleBinding. This flexibility is often overlooked.
Mistake
The 'default' service account is safe to use because it has no permissions by default.
Correct
The 'default' service account in many default configurations is automatically mounted into every pod and often has no permissions — but this is a security risk precisely because it is mounted everywhere. Attackers can use it to probe the API server. The best practice is to disable automatic mounting of the 'default' service account and create dedicated ones.
Beginners assume 'no permissions' means 'safe', but the mere presence of credentials inside a pod is a risk. An attacker who compromises the pod can use those credentials to attempt actions, and if misconfigured, they might succeed.
Mistake
RBAC is the only way to control access in Kubernetes.
Correct
RBAC is the primary method, but Kubernetes also supports other access control mechanisms such as ABAC (Attribute-Based Access Control), Webhook token authentication, and Node authorisation. However, RBAC is the recommended and most commonly used method.
Exam study materials often emphasise RBAC heavily, leading beginners to think it is the only choice, but the exam expects you to know that other authorisation modes exist and can be configured.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Role grants permissions to resources within a single namespace, like pods in 'namespace-a'. A ClusterRole grants permissions to resources that are cluster-wide, like nodes or persistent volumes, or to resources in any namespace when used with a RoleBinding.
Yes. Create a RoleBinding in that namespace that references the ClusterRole. The permissions defined in the ClusterRole will then apply only within that namespace, not cluster-wide.
The default service account has no permissions, but it is automatically mounted into every pod. If an attacker compromises a pod, they can use the default service account's credentials. A dedicated service account with minimal permissions limits the blast radius of any compromise.
Use the command 'kubectl auth can-i --list --as=username' for a user, or 'kubectl auth can-i --list --as=system:serviceaccount:namespace:sa-name' for a service account. This lists every action they are allowed to take.
It means giving a user or service account only the minimum permissions required to perform its intended job. For example, if an app only needs to read pod logs, do not grant it permissions to delete pods or create deployments.
Configure your Kubernetes cluster to use an OIDC (OpenID Connect) provider. Microsoft Entra ID acts as the OIDC provider. Users log in with their Microsoft Entra ID credentials, and the cluster maps them to Kubernetes users. You then use RBAC to grant those users permissions.
Kubernetes rejects this. A RoleBinding must reference a Role that exists in the same namespace. To use a Role from another namespace, you must use a ClusterRole instead, which can be bound via a RoleBinding in any namespace.
You've finished RBAC, Service Accounts, and IAM. Continue through the CKS study guide to build a complete picture of the exam.
Done with this chapter?