Kubernetes RBAC Permission Authentication: Concepts, Components, and Production Scenarios

Kubernetes (K8s) permission authentication involves a series of security interactions among several components. A user or program sends a request to the API Server, which performs authentication and authorization before delegating the command to the appropriate component (e.g., Kubelet) for execution.

In simple terms, authentication determines who is allowed to perform what operations on which resources . The three key questions are:

Who : the requester, usually a ServiceAccount (SA) representing a program or a human.

What resources : Kubernetes objects such as Pods, Deployments, Services, Namespaces, etc.

What operations : verbs like get, list, watch, create, update, patch, delete.

RBAC (Role‑Based Access Control) is the mechanism Kubernetes uses to manage these permissions. It relies on the following core components:

ServiceAccount (SA) : an identity used by pods or applications.

Role : defines permissions (resource + verb) within a namespace.

RoleBinding : binds a Role to a ServiceAccount, granting the defined permissions.

ClusterRole : similar to Role but scoped to the entire cluster.

ClusterRoleBinding : binds a ClusterRole to a ServiceAccount for cluster‑wide permissions.

A Role can include verbs such as get, list, watch, create, update, patch, and delete.

Production Scenario 1 – TCF Framework

In a production environment, the TCF framework requires long‑lived connections between Pods. Because the default Kubernetes Service uses round‑robin load balancing, a custom load‑balancing approach is needed: first retrieve the IP addresses of all target Pods and then perform load balancing in application logic.

Permission requirements for the client Pod (Pod A) are:

Get – to read the IP addresses of target Pods.

List – to enumerate all target Pods.

Watch – to monitor changes and update IPs when Pods are recreated or removed.

Implementation steps:

Create a ServiceAccount for the client application.

Create a Role that grants get, list, and watch on Pods.

Create a RoleBinding to bind the Role to the ServiceAccount.

Optionally create a ClusterRole and ClusterRoleBinding if cluster‑wide permissions are needed.

A complete YAML manifest (shown in the original images) demonstrates these resources. After applying the RoleBinding, the permissions can be verified with kubectl auth can-i get pod --as=system:serviceaccount:namespace:my-app-sa , which returns “yes” if the binding is effective.

Production Scenario 2 – Administrator Access

Administrators also use RBAC. Since they cannot use a ServiceAccount directly, they obtain a token from a Secret associated with a ServiceAccount. The token is placed in the client-key-data field of the kubeconfig file, granting admin privileges.

Permission requirement: full access (verb * ) to all resources.

Implementation steps:

Create a ServiceAccount for the administrator.

Create a ClusterRole with * permissions.

Create a ClusterRoleBinding to bind the ClusterRole to the ServiceAccount.

Create a Secret that references the ServiceAccount; the token extracted from this Secret is used in kubeconfig.

After applying the Secret, the token can be retrieved with kubectl get secret admin-token -n kube-system -o yaml and inserted into the kubeconfig to enable admin‑level kubectl commands.

Conclusion

The two production examples illustrate how RBAC is configured and applied in real‑world Kubernetes clusters. The same principles can be extended to other permission‑sensitive scenarios, providing a flexible, secure, and principle‑of‑least‑privilege approach to access control.