Role-Based Access Control (RBAC) and ServiceAccounts

Role-Based Access Control (RBAC) is a method of regulating access to resources based on the roles of individual users or automated processes. In Kubernetes, it is how you control who can do what within your cluster. Before RBAC, many systems used a simpler model: either you were an admin (full access) or you had no access. That approach is fragile and dangerous — one person with too much power can accidentally break everything. RBAC replaces that with a fine-grained, least-privilege approach.

At its heart, Kubernetes RBAC has four key components: Rules, Roles, Subjects, and RoleBindings. Let's define each.

A Rule is a single permission statement. It specifies an API group (the category of resource, like 'apps' for Deployments), a resource (like 'pods' or 'services'), and verbs (actions like 'get', 'list', 'create', 'delete'). For example, a rule might say: 'allow the get and list verbs on pods in the core API group'.

A Role is a collection of rules. You group related rules together into a single Role. There are two types of Roles in Kubernetes. A regular Role applies to a specific namespace (a virtual cluster within your cluster). A ClusterRole applies to the entire cluster, across all namespaces. For example, you might have a 'pod-reader' Role in the 'production' namespace that contains rules for reading pods and services. If you need to grant the same permissions across every namespace, you would use a ClusterRole.

A Subject is the entity that gets the permission. It can be a User (a real person), a Group (a collection of users), or a ServiceAccount (an identity for automated processes, like a running application). In Kubernetes, Users and Groups are often managed by an external system like Microsoft Entra ID, but ServiceAccounts are native Kubernetes objects that live inside the cluster.

A RoleBinding (or ClusterRoleBinding) is the link between a Role and a Subject. It says 'this role's permissions are now granted to this subject'. A RoleBinding works within a specific namespace, and a ClusterRoleBinding works cluster-wide. If you create a RoleBinding that attaches the 'pod-reader' Role to the 'my-service-account' ServiceAccount in the 'production' namespace, then that ServiceAccount can now get and list pods only in that namespace.

ServiceAccounts are a special kind of subject. They are not people; they are identities for workloads that run inside a pod. Every pod is automatically assigned a ServiceAccount (the 'default' ServiceAccount in its namespace) unless you specify a different one. You can create custom ServiceAccounts for different applications. For example, you might have a 'monitoring-serviceaccount' with read-only access to pods and services, and a 'build-serviceaccount' with permission to create and delete jobs.

When you create a pod and assign it a ServiceAccount, Kubernetes automatically mounts a token into the pod. This token is a secret credential that the application inside the pod uses to authenticate to the Kubernetes API server. The API server checks the token, identifies which ServiceAccount it belongs to, and then checks the RoleBindings to see if that ServiceAccount is allowed to perform the requested action. If the token does not have the right permissions, the API server denies the request with a '403 Forbidden' error.

The combination of Roles, RoleBindings, and ServiceAccounts gives you extremely fine-grained control. You can create a Role that allows only listing pods (no creating or deleting), bind it to only one ServiceAccount, and that ServiceAccount's applications are locked down. This is critical for security and reliability. If an application runs with a ServiceAccount that only has read access to its own namespace, even if the application is compromised, the attacker cannot touch other namespaces, cannot delete data, and cannot see other teams' secrets.

Kubernetes also supports aggregation of ClusterRoles, allowing you to build complex permission sets from smaller, reusable pieces. But for the CKAD exam, the fundamental workflow is: create a Role (or ClusterRole), create a ServiceAccount, then create a RoleBinding (or ClusterRoleBinding) to connect them. You will need to write YAML files that define these objects.

Remember: Roles are namespaced, ClusterRoles are not. RoleBindings bind namespaced roles to subjects within a namespace. ClusterRoleBindings bind cluster-scoped roles to subjects and apply to all namespaces. You can also bind a ClusterRole to a subject within a specific namespace using a RoleBinding — that is a common pattern to reuse a set of cluster-wide permissions but limit them to one namespace.

Imagine you work at a company called 'FinSave', a financial services startup that runs its applications on Kubernetes. The platform team manages three namespaces: 'production', 'staging', and 'developer-sandbox'. Each namespace runs microservices for different parts of the banking application. You, as a platform engineer, must ensure that developers can see logs and troubleshoot their own services, but cannot touch other teams' services or, most importantly, delete production data.

Here is how you use RBAC and ServiceAccounts in practice. First, you identify the different roles needed. - The 'development-team' role needs read-only access to pods and services in their own namespace, plus the ability to view logs. They should not be able to create or delete anything. - The 'ci-cd-pipeline' ServiceAccount needs permission to create and update Deployments and Services in the staging namespace, but only read access in production (to verify deployments succeeded). - The 'monitoring-system' ServiceAccount needs cluster-wide read access to metrics endpoints on pods and nodes, but nothing else. - The 'security-auditor' role (a person) needs read-only access to all namespaces, including access to Secrets (to check encryption) but no ability to modify them.

You start by creating ClusterRoles for the security auditor (cluster-wide read access) and the monitoring system (read-access to metrics). For the development team, you create a namespaced Role called 'developer-readonly' in each namespace. For the CI/CD pipeline, you create a namespaced Role in staging that permits create, update, and read on Deployments and Services. Then you create a separate Role in production with only read access.

Next, you create ServiceAccounts. For the CI/CD pipeline, you create a ServiceAccount called 'build-bot' in the 'staging' namespace. For monitoring, you create 'monitoring-agent' in the 'kube-system' namespace. For developers, you might create a ServiceAccount per team or use their user identities from Microsoft Entra ID.

Then you create the RoleBindings. You bind the 'developer-readonly' Role to the development team's user group (authenticated via Microsoft Entra ID) using a RoleBinding in each team's namespace. You bind the 'ci-cd-staging-role' to the 'build-bot' ServiceAccount in staging. You bind the 'ci-cd-production-readonly' Role to the same 'build-bot' ServiceAccount in production. You bind the 'monitoring-clusterrole' to the 'monitoring-agent' ServiceAccount using a ClusterRoleBinding. Finally, you bind the 'security-auditor-clusterrole' to the auditor's user identity using a ClusterRoleBinding.

After this setup, you test by trying to access the production API as the 'build-bot' token — you can list deployments, but a delete request returns a 403 error. The application is safe. Every automated process and human being has exactly the access it needs, and nothing more. If a new developer joins, you just add them to the correct group in Microsoft Entra ID, and the existing RoleBindings automatically grant the correct permissions. If a developer leaves, you remove them from the group — no manual cleanup needed.

This is day-to-day work for a Kubernetes administrator and a critical skill for the CKAD exam. You must be comfortable writing YAML manifests that define Roles, RoleBindings, ServiceAccounts, and understanding how they connect.