How does a Kubernetes cluster stop the wrong person — or the wrong application — from deleting critical data or accessing secret configuration files? This is the exact problem that security and role-based access control solve, and it shows up in nearly every KCNA exam domain. Without a clear permission system, every user and every automated script would have the same god-level power, turning a single small mistake into a full cluster outage. Understanding RBAC, ServiceAccounts, and security contexts gives you the mental model to answer exam questions about least-privilege access, identity management, and pod-level hardening — all of which appear in the exam objectives.
Jump to a section
A simple way to picture Security and RBAC in Kubernetes
A bank vault is the most secure room in a financial institution, but its technology is useless without a system that controls who can open which door.
In this bank, different staff members have different badges. A teller's badge opens the front door and their cash drawer, but it does not open the vault. A branch manager's badge opens the vault door and the safe-deposit box room, but it does not open the IT server closet. An IT technician's badge opens the server closet and the alarm panel, but it does not open any cash drawer. Each badge is a ServiceAccount in Kubernetes — a digital identity for a person or a program. The bank's rulebook that says 'tellers can open drawers but not the vault' is exactly like an RBAC Role or ClusterRole. The act of pinning a specific badge to a specific person is like a RoleBinding or ClusterRoleBinding. The badge reader at each door is the API server checking 'does this identity have permission for this action on this resource?' before it lets anyone through. Without this system, anyone with a master key could drain the vault, and the bank would fail. Kubernetes uses the same logic: you give each workload (container or pod) exactly the permissions it needs to do its job — and no more.
Kubernetes is a platform for running containerised applications across many machines. When you have more than one person or automated system interacting with the cluster, you need a way to say 'this user can see pods in this namespace but cannot delete them' and 'that automated script can read logs but cannot create new deployments'. That is exactly what Role-Based Access Control (RBAC) does.
RBAC stands for Role-Based Access Control. It is the primary method Kubernetes uses to authorise actions. Authorisation means deciding whether an already-identified user is allowed to perform a specific operation. This is different from authentication (proving who you are). RBAC answers the question 'now that I know who you are, what are you allowed to do?'
Let us define the core objects you need to know for the exam:
ServiceAccount: A ServiceAccount is an identity for a process or an application running inside a pod. Think of it as a 'robot user'. Every pod is assigned a ServiceAccount. If you do not specify one, the pod uses the default ServiceAccount in its namespace. ServiceAccounts are how pods authenticate themselves to the Kubernetes API server.
Role and ClusterRole: A Role is a set of rules that define what actions are allowed on which resources within a single namespace. For example, a Role might say 'allow get, list, and watch on pods' but 'deny everything on secrets'. A ClusterRole is the same kind of rule set, but it applies across the entire cluster, not just one namespace. ClusterRoles are used for cluster-wide resources like nodes or PersistentVolumes, and for resources in all namespaces.
RoleBinding and ClusterRoleBinding: A RoleBinding connects a Role to a user, group, or ServiceAccount within a specific namespace. For example, you create a Role called 'pod-reader' and then create a RoleBinding in the 'production' namespace that attaches that Role to 'john-doe-user'. A ClusterRoleBinding does the same thing but at the cluster level.
Here is how the flow works in practice:
A person or a pod makes an API request (e.g., 'get me a list of pods').
The API server authenticates the requester (identifies who they are).
The API server then checks authorisation: it looks up the relevant RoleBindings or ClusterRoleBindings for that identity.
It matches the request verb (get, list, create, delete, update) and the resource (pods, secrets, deployments) against the rules in the bound Roles or ClusterRoles.
If at least one rule grants permission, the request is allowed. If no rule matches, the request is denied (the default is deny).
Now let us talk about security contexts. A SecurityContext is a set of constraints at the pod or container level that controls what the running process is allowed to do on the host operating system. This is different from RBAC, which controls access to the Kubernetes API. A security context controls things like:
Whether the container can run as a privileged user (root).
Which Linux user ID (UID) and group ID (GID) the process uses.
Whether the container can mount host filesystems.
Whether it can use host networking.
Whether it can escalate privileges (gain more permissions than its parent process).
For the KCNA exam, you need to understand that security contexts are the final safety layer inside the node. Even if RBAC allows a pod to be created, the security context can prevent that pod from doing dangerous things like reading the host's filesystem.
Why does Kubernetes have all these separate mechanisms? The principle is called 'defence in depth'. RBAC controls access to the API. ServiceAccounts give identity to software. Security contexts restrict what a running container can do even if it gets compromised. Each layer catches different types of threats. A compromised application that bypasses RBAC (because it is the legitimate ServiceAccount) is still limited by its security context.
Before RBAC, Kubernetes used a simpler system called ABAC (Attribute-Based Access Control), which was a single flat policy file that had to be edited and reloaded manually every time you wanted to change permissions. RBAC replaced it because ABAC was not scalable, had no native support for groups, and was extremely difficult to audit. RBAC is now the default and only recommended authorisation mode for production clusters.
Identify the identity
Determine who or what is making the request. Is it a human user with a certificate or token, or is it a pod using a ServiceAccount? The identity is the starting point for all authorisation checks.
Create a Role or ClusterRole
Define the exact permissions needed. List the API resources (e.g., pods, secrets) and verbs (e.g., get, list, create, delete) that the identity requires. Use a Role for namespace-scoped permissions and a ClusterRole for cluster-wide or cross-namespace permissions.
Create a RoleBinding or ClusterRoleBinding
Bind the Role or ClusterRole to the identity (user, group, or ServiceAccount) using a RoleBinding for namespace-scoped bindings or a ClusterRoleBinding for cluster-wide bindings. This is the step that actually grants the permissions.
Configure the SecurityContext on the pod
Set the pod or container spec to include a securityContext that enforces constraints like runAsNonRoot, runAsUser, readOnlyRootFilesystem, and capability drops. This limits what the process can do inside the node, even if the RBAC rules allow pod creation.
Test and verify using kubectl
Use commands like 'kubectl auth can-i' or 'kubectl --as=system:serviceaccount:namespace:name auth can-i get pods' to check what an identity can actually do. This confirms that the RBAC rules and bindings work as expected and catches misconfigurations.
Imagine you work for a travel booking company called FlyFast. The company runs its entire microservices platform on a Kubernetes cluster with three namespaces: development, staging, and production.
Your first task as a junior platform engineer is to set up access for the new developer hired to work on the payment microservice. You do not just give them a cluster admin certificate. Instead, you do the following:
You create a new ServiceAccount called 'payment-svc-account' in the development namespace. This is the identity for the payment service itself. The service will use this account to talk to the API server.
You create a Role called 'payment-dev-role' in the development namespace. The role contains rules that allow the following: get, list, and watch for pods and deployments; create and update for secrets (because the payment service needs to store API keys); but deny all operations on nodes (which are cluster-wide) and deny any delete operations.
You create a RoleBinding called 'payment-dev-binding' that binds the 'payment-dev-role' to the newly hired developer's user identity (which was already imported from the company's Microsoft Entra ID).
Separately, you configure a SecurityContext on the payment service's pod spec. You set 'runAsNonRoot: true' and 'runAsUser: 1000' so that the process inside the container runs as a non-root user. You also set 'readOnlyRootFilesystem: true' so that even if an attacker exploits a vulnerability in the Node.js runtime, they cannot modify system binaries.
Now, a few weeks later, the monitoring team needs read-only access to production logs. You do not give them a cluster admin role. Instead, you create a ClusterRole called 'log-reader' that allows get and list on pods and logs across all namespaces. Then you create a ClusterRoleBinding for the monitoring team group. This grants them access everywhere, but only to read logs — they cannot restart deployments or modify anything.
What happens when someone tries to exceed their permissions? Suppose the new developer accidentally runs 'kubectl delete pod payment-svc-abc'. The API server checks the RoleBinding, finds that the developer's role does not include a delete verb for pods, and denies the request with a '403 Forbidden' error. The developer sees an error message, nobody panics, and production stays up.
The KCNA exam will test your ability to read a RBAC manifest and say what it allows. For example, given a YAML file that creates a Role with 'verbs: [get, list]' on 'resources: [pods]', you need to know that a user bound to that role can read pod information but cannot create, delete, or update them. Another common scenario involves debugging why a pod cannot talk to the API server: you would check if the ServiceAccount exists and if a RoleBinding exists in the correct namespace.
The KCNA exam includes several question types that specifically test RBAC, ServiceAccounts, and security contexts. Here is what you need to be ready for. - Distinguishing a Role from a ClusterRole: This is the most common trap. The exam will give you a manifest and ask 'which namespace does this apply to?' If the YAML says 'kind: Role', it only applies to the namespace listed in the 'metadata.namespace' field. If it says 'kind: ClusterRole', it is cluster-wide. The exam might present a scenario where a ClusterRole is bound with a RoleBinding (which limits it to one namespace) — you need to understand that a ClusterRole can be used in a RoleBinding to grant cluster-level permissions to only one namespace. - Verb and resource matching: The exam will ask 'a user with this role can perform which actions?' You must know the common verbs: get, list, watch, create, update, patch, delete. The resources include pods, deployments, services, secrets, configmaps, nodes, and persistentvolumes. If a verb is not listed, it is denied. - Default ServiceAccount: Many beginners think every pod has no ServiceAccount by default. The truth is that every pod is automatically assigned the 'default' ServiceAccount in its namespace. This default ServiceAccount often has very few permissions (maybe none), which is why many beginner tutorials get a '403' error when they try to list pods from inside a container — the default ServiceAccount has no RBAC bindings. - SecurityContext vs. PodSecurityPolicy vs. PodSecurity admission: The exam focuses on the newer PodSecurity admission (which is part of Kubernetes 1.23+). PodSecurityPolicy is deprecated and will not be tested heavily, but you should know it existed. PodSecurity admission uses three modes: privileged, baseline, and restricted. You will be asked which mode provides the strongest security restrictions (restricted). - Group and user impersonation: The exam might present a scenario where a ServiceAccount is bound to a Role, and then a pod uses that ServiceAccount. You need to know that the pod's requests to the API server are made as that ServiceAccount, not as the human who runs kubectl.
Specific traps to watch for:
Trap 1: The exam asks 'What happens if no RoleBinding exists for a ServiceAccount?' Answer: the ServiceAccount can do nothing — every request is denied with a 403, because Kubernetes authorisation defaults to deny.
Trap 2: The exam says 'a user creates a Role with rules for secrets but only lists pods in the rules'. The correct answer is that the user cannot access secrets, because the role did not include the secrets resource.
Trap 3: The exam asks about aggregate roles — ClusterRoles that are combined. You do not need to memorise every aggregate role, but you should know that some roles like 'admin', 'edit', and 'view' are built-in ClusterRoles that Kubernetes creates automatically. Knowing that 'view' is read-only and 'edit' can modify resources (but not RBAC rules) is helpful.
Key definitions to memorise:
RBAC: authorisation method that maps users/groups/serviceaccounts to rules
ServiceAccount: an identity for a pod or process
SecurityContext: runtime constraints on a container or pod
RoleBinding: binds a Role to a subject in a namespace
ClusterRoleBinding: binds a ClusterRole to a subject cluster-wide
PodSecurity admission: Kubernetes built-in admission controller that enforces security standards
RBAC is the primary authorisation method in Kubernetes, controlling what authenticated users and ServiceAccounts can do with the API.
A ServiceAccount is a machine identity for a pod, not a human user account, and every pod has one even if you do not specify it.
A Role applies to a single namespace, while a ClusterRole applies cluster-wide; both are sets of rules listing allowed verbs and resources.
A RoleBinding links a Role (or ClusterRole) to a specific subject within one namespace, and a ClusterRoleBinding links a ClusterRole to a subject across all namespaces.
SecurityContext controls the runtime privileges of a container — like whether it runs as root or can mount host filesystems — separate from API access.
The default deny rule in Kubernetes means any action not explicitly allowed by a Role or ClusterRole is forbidden.
PodSecurity admission replaces the deprecated PodSecurityPolicy and enforces restricted, baseline, or privileged modes on pods.
Aggregated built-in ClusterRoles like 'view', 'edit', and 'admin' are predefined and commonly tested in the exam.
A common exam trap: a Role with get and list on pods does not allow create, delete, or update — only explicitly listed verbs are allowed.
You can bind a ClusterRole to a RoleBinding to grant cluster-wide permissions only within one namespace.
These come up on the exam all the time. Here's how to tell them apart.
Role
Applies only to a single namespace
Cannot grant permissions to cluster-scoped resources like nodes
Must be bound with a RoleBinding in the same namespace
ClusterRole
Applies across all namespaces and to cluster-scoped resources
Can grant permissions to nodes, PersistentVolumes, and namespaces
Can be bound with a RoleBinding (namespace-scoped) or ClusterRoleBinding (cluster-wide)
RoleBinding
Binds a subject to a Role or ClusterRole within one namespace
Scope is limited to the namespace in the metadata
The subject only gets permissions in that namespace
ClusterRoleBinding
Binds a subject to a ClusterRole across the entire cluster
Scope is cluster-wide
The subject gets permissions in all namespaces and on cluster-scoped resources
ServiceAccount
Machine identity for a pod or process
Managed as a Kubernetes resource (kind: ServiceAccount)
Tokens are automatically mounted into pods
User Account
Human identity (e.g., person using kubectl)
Managed externally via certificates or identity provider (e.g., Microsoft Entra ID)
No automatic token mounting; requires manual configuration
RBAC
Controls access to the Kubernetes API (pods, secrets, etc.)
Uses Roles, ClusterRoles, RoleBindings, ClusterRoleBindings
Decision is made at the API server before the request reaches the node
SecurityContext
Controls runtime privileges of a container on the host OS
Configured in the pod or container spec (securityContext field)
Enforced by the kubelet on the node after the pod starts
Mistake
ServiceAccounts are only for human users, not for pods or applications.
Correct
ServiceAccounts are specifically designed for pods and automated processes. Human users typically authenticate via certificates or external identity providers like Microsoft Entra ID, not ServiceAccounts.
The word 'account' in ServiceAccount makes beginners think of a human user account, but in Kubernetes it is a machine identity.
Mistake
If you create a Role in a namespace and a RoleBinding in the same namespace, the permissions apply to all users automatically.
Correct
A RoleBinding explicitly binds a Role to a specific subject (user, group, or ServiceAccount). No one gets those permissions unless the RoleBinding names them. The default state for everyone is 'deny all'.
People assume that creating a Role is like creating a group policy that applies broadly, but Kubernetes requires an explicit binding step for each identity.
Mistake
SecurityContext is exactly the same thing as RBAC.
Correct
RBAC controls access to the Kubernetes API (e.g., who can create pods). SecurityContext controls what the running process inside the pod can do on the host operating system (e.g., run as root or not). They are separate security layers.
Both concepts deal with permissions, so beginners conflate them. The exam deliberately tests whether you know the difference between API-level authorisation and node-level security.
Mistake
If a pod uses the default ServiceAccount, it has no permissions at all.
Correct
The default ServiceAccount exists and is automatically mounted into every pod, but it typically has no RBAC bindings, so requests from that pod to the API server are denied. However, it still has an identity — it just has no permissions.
Seeing 'no permissions' leads beginners to think the ServiceAccount does not exist or is null. It exists, but it is unprivileged.
Mistake
ClusterRoleBindings are only for administrator access.
Correct
ClusterRoleBindings are for binding a ClusterRole to a subject across all namespaces, but ClusterRoles can be non-administrative. For example, a 'view' ClusterRole allows read-only access cluster-wide. ClusterRoleBindings can grant limited permissions, not just full admin.
The word 'cluster' sounds powerful, so beginners assume it always means admin-level access.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Role defines permissions within a single namespace, while a ClusterRole defines permissions that apply across the entire cluster, including to cluster-scoped resources like nodes and PersistentVolumes.
Create a ServiceAccount manifest using kind: ServiceAccount and a name, then reference that ServiceAccount in your pod spec under 'serviceAccountName'. If you do not specify one, the pod uses the default ServiceAccount in its namespace.
The pod's ServiceAccount lacks a Role or ClusterRole that grants the 'list' verb on the 'pods' resource. You need to create a Role with that permission and bind it to the ServiceAccount using a RoleBinding in the same namespace.
Yes, but that is a security risk. Best practice is to give each ServiceAccount the minimum permissions needed for its task (least privilege), and use different ServiceAccounts for different applications, not a shared one.
A security context controls runtime privileges for a container (like running as root or mounting host paths), while RBAC controls access to the Kubernetes API. They are complementary security layers.
The ClusterRole's permissions are granted, but only within the namespace of the RoleBinding. This is a common way to reuse a ClusterRole (like 'view') for namespace-scoped access.
You've finished Security and RBAC in Kubernetes. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?