Kubernetes RBAC

RBAC (Role-Based Access Control) is the Kubernetes authorization model that controls who can do what inside the cluster.

Without RBAC, users and workloads could perform any action they wanted against Kubernetes resources.

An authorization model defines how permissions are granted and enforced.

An identity is the user, service account, or system account that requests access to an API.

A user is an identity recognized by the cluster, often through external authentication systems such as OIDC, LDAP, or certificates.

A service account is an identity used by pods or workloads to access Kubernetes resources.

A Role grants permissions within a single namespace.

A ClusterRole grants permissions across the entire cluster, not just one namespace.

A RoleBinding associates a Role with one or more subjects within a namespace.

A ClusterRoleBinding associates a ClusterRole with one or more subjects cluster-wide.

A subject is a user, group, or service account that is granted access via a Role/RoleBinding or ClusterRole/Binding.

A RoleRef points from a RoleBinding or ClusterRoleBinding to the actual Role or ClusterRole.

Resources include Pods, Services, Secrets, Deployments, ConfigMaps, and many others.

A verb is the action allowed on a resource, such as get, list, create, update, delete, patch, or watch.

A resource is the Kubernetes API object that the permission applies to.

A resource name may restrict access to a specific object instance.

Because permissions are expressed as “who can do what and on which resources.”

Least privilege means giving only the permissions required for a task.

It reduces damage if an account or workload is compromised.

Cluster-admin is a highly privileged ClusterRole that can do almost anything.

Because it grants wide control over the cluster and its workloads.

A read-only role allows observation but not modification of resources.

A namespace-scoped user has permissions inside a single namespace or a limited set of namespaces.

Cluster-scoped access applies across all namespaces or cluster-level resources.

The API server is the central control plane component responsible for authorization, authentication, and resource handling.

Authentication confirms who the caller is.

Authorization decides whether the caller is allowed to perform the requested action.

The boundary where the caller is identified before RBAC is applied.

Because a caller may be authenticated but still not authorized for a specific action.

A service account token is the credential used by pods or controllers to authenticate to the Kubernetes API.

Every namespace gets a default service account unless a different one is specified.

It may grant unnecessary permissions or be used by workloads without explicit credentials.

The subject type can be a user, group, or service account.

A group is a set of users or identities with shared permissions.

A namespace user is usually an identity associated with that namespace via a service account or admin-managed auth.

Token review verifies a token presented by a caller and extracts its identity.

Admission control is the API layer that can reject or mutate requests before they are stored.

Because authorization and policy enforcement happen around the same API traffic lifecycle.

It limits a permission to a specific named resource instance rather than all resources of a type.

Some permission rules can be broader, though Kubernetes RBAC usually uses clear resource and verb sets.

Because the cluster should not allow broad, unclear permissions by default.

The API group is the logical grouping of resources, like apps, batch, networking.k8s.io, etc.

A resource kind is the Kubernetes object type, such as Pod, Deployment, Secret, ConfigMap.

A subresource is a smaller part of a resource, such as /status or /scale.

Because a user may need access to a pod status or scale endpoint but not the whole resource.

A watch permission grants the ability to watch resource changes over time.

A list permission grants the ability to enumerate resources.

A get permission allows reading a specific resource.

A create permission allows creating new objects of a specific type.

Update permission allows replacing or modifying an existing resource.

Delete permission permits deleting resources.

Patch permission allows partial updates to a resource.

Impersonation lets one identity act as another identity for debugging or testing permissions.

It helps administrators test what a user or service account can do without changing their credentials.

An RBAC audit reviews who has what permissions and whether those permissions are still necessary.

Because over-broad permissions accumulate over time and can be a major security risk.

A deny-by-default model gives no permission unless explicitly granted.

It reinforces least privilege and makes permission design more intentional.

It is the most privileged cluster-level role and should be tightly restricted.

A pod reader role might allow listing and getting pods but not creating or deleting them.

A deployer role might allow create/update/delete on Deployments and related resources.

It may allow reading Secret objects, which is highly sensitive and should be limited.

Because Secret data can expose credentials, certificates, and tokens.

RBAC is one of the main policy controls that restricts what users and workloads can access.

Because many permissions are namespaced and should not reach beyond a limited boundary.

It binds a ClusterRole to a subject only inside a namespace, creating a limited but cluster-wide logical role.

An example subject is a user, a group, or a service account in a namespace.

A service account in another namespace or a group of administrators.

It may create hidden privileges and overbroad access if not monitored.

Different identities handle different parts of cluster operations to reduce blast radius and insider risk.

An operator is an application controller that watches Kubernetes resources and performs cluster-level actions.

Because operators often need broad permissions to reconcile resources and maintain cluster state.

A controller manager is part of the Kubernetes control plane and may require elevated permissions to manage resources.

Because they coordinate cluster behavior and health.

A kubeconfig is a file that stores cluster connection parameters and user credentials.

Because it can grant broad cluster access if stolen.

An authentication provider is an external identity source such as OIDC, LDAP, or certificate-based auth.

Because they centralize identity management and support stronger security policies.

OIDC is an identity protocol widely used to authenticate users to Kubernetes via external identity providers.

Because an authorization system needs trusted identities to make decisions.

A user certificate is a client certificate used for Kubernetes API authentication.

The API is usually served via TLS so credentials are not exposed in transit.

The chain includes identity discovery, token or certificate validation, and RBAC authorization.

Because the token is only the identity; authorization still evaluates allowed API actions.

Users can accidentally create or delete resources or read secrets they should not access.

A Secret may expose credentials, certificates, tokens, or private keys.

Privilege escalation is when a compromised or lower-privileged identity gains wider access.

Because it constrains which identities can grant or acquire more permissions.

It grants a workload running as a service account the permissions in that Role.

Because it limits a workload to only the API actions that its Role allows.

The pod may use this token to authenticate to the API server for tasks like discovery or secret access.

Short-lived tokens reduce the risk of misuse if they are leaked.

The token audience identifies which service or API the token is intended for.

The kubelet uses credentials to communicate with the API server and manage pods.

This is a common high-risk pattern if misconfigured or overused.

Because they are namespaced and more limited.

• granting cluster-admin too broadly
• over-permissive service accounts
• using broad verbs like * on Secrets
• binding roles to the wrong subjects
• not reviewing permissions over time

A wildcard may grant create, update, delete, get, list, watch, and patch broadly.

They can unintentionally grant more access than intended.

It ties authorization to identity and resource access, not just API exposure.

The authorization API decides whether a request is allowed based on role and policy rules.

A policy decision is the result of an authorization query: allow or deny.

The cluster denies the request if no matching permission is found.

A request is authenticated, then authorized by checking the relevant Role/ClusterRole bindings.

The request context includes the user, group, API method, resource, namespace, and subresource.

Because the same identity can have different access depending on the request.

It is the URL path to the API object, such as /api/v1/namespaces/default/pods.

It is a more specific part of an object, such as /pods/{name}/log or /pods/{name}/exec.

Because some actions, like streaming logs or executing in a container, should be tightly controlled.

Reading pod logs may expose application output and debugging information.

Pod exec lets a user execute commands inside a container, which is a high-risk action.

Because it can compromise the application or expose secrets inside the container.

A Role can allow get on pods/log but not exec or delete.

Because logs may contain plaintext secrets, API keys, or sensitive request data.

A SecurityContext can impose restrictions on the pod or container, such as running as non-root.

They complement each other: RBAC controls API access; SecurityContext controls runtime privileges within the pod.

A PodSecurityPolicy is an older admission control mechanism used to restrict pod behavior.

Pod Security Admission is a newer policy framework that enforces restricted security levels.

Because both are security controls over workloads, but they govern different aspects.

A RoleBinding or ClusterRoleBinding can target a user or group rather than a service account.

Groups simplify management by granting the same permissions to a set of users.

An admin group often receives ClusterRole-binding permissions to manage cluster operations.

Because adding or removing a user from a group changes permissions centrally.

A ClusterRole can apply across namespaces to support shared operational functions.

A Role is limited to one namespace and often easier to reason about.

Because they reduce scope and risk compared with cluster-wide grants.

It often means the caller lacks permission or the object may not exist.

Because the API server enforces access control before returning data.

It is a tool to check whether a subject can perform a given action.

It helps validate and test RBAC permissions without changing the configuration.

A policy review examines if the current RBAC rules align with expected operations and least privilege.

Teams may get admin access within their own namespace but not cluster-wide.

A cluster operator role may manage nodes, workloads, and cluster-level services.

A secrets manager role may read or rotate secrets but should be tightly scoped and audited.

Because tools like ArgoCD, Flux, Helm, and service meshes need specific permissions.

It is the set of permissions given to GitOps controllers to reconcile cluster resources.

Because it can create, update, and delete cluster objects based on Git changes.

An operator may need get/list/watch on CustomResourceDefinitions, Deployments, and Secrets.

It is a mechanism to compose roles using multiple policy fragments.

To build reusable permission sets for multiple operators or teams.

Authorization policy grows over time, making review and auditing essential.

It is a matrix of identities and the resources/verbs they can access.

It is the accumulation of permission changes that no longer reflect current operational needs.

Because teams change, workloads evolve, and unnecessary permissions accumulate over time.

Many token systems allow tokens to expire or rotate automatically.

Because leaked tokens are less useful after expiry, and they can be rotated without full identity changes.

It can restrict which services accept a token as valid.

Namespace isolation is a broader design principle supported by RBAC and network controls.

Because they reduce cross-namespace blast radius and make ops safer.

A ClusterRole that reads Secrets across namespaces is a high-risk privilege and should be audited carefully.

Because support users may need to inspect resources without changing them.

It allows both observation and modification, typically for operators or application teams.

A custom role is a Role or ClusterRole created specifically for the organization’s operational needs.

Because it grants too broad a scope and can create operational or security hazards.

Custom resources can also be protected by Roles and ClusterRoles like built-in resources.

Because operators and controllers often manage CRDs with custom logic and resources.

A controller with broad permissions may accidentally mutate or delete more than intended.

It verifies whether the role is necessary and whether the verbs and resources are as narrow as possible.

Because it affects identity and trust across the cluster and the workloads that depend on it.

Service accounts are the common identity for workloads, and RBAC grants them permissions through RoleBindings.

So they can authenticate to APIs such as the Kubernetes API and other internal systems.

Because many workloads run under it by default unless explicitly assigned.

It is a common best practice to avoid sharing service accounts across unrelated workloads.

It reduces blast radius and allows fine-grained permission assignments.

A specific deployment or app gets a service account and a RoleBinding with only the necessary permissions.

It may use a specific group or service account to grant read-only access to observability tools.

A monitoring or dashboard user might need list/watch/read access but not create/delete powers.

Because secret enumeration exposes names and may lead to further attacks.

It allows platform operators to maintain cluster-level tools while keeping user workloads isolated.

Yes. RBAC restricts API access, while PodSecurity and NetworkPolicy restrict runtime and network behavior.

Network reachability is about packet flow; RBAC reachability is about API actions and policy decisions.

Because it is a central control plane and a high-value target.

Because the API server must authenticate callers securely and trust them appropriately.

It is how the K8s environment verifies identity before RBAC evaluation.

It includes the user details and group metadata used for policy decisions.

It is the separation between those who manage infrastructure and those who manage application workloads.

Because they are responsible for keeping the API control plane secure and stable.

• explicit identity
• narrow permissions
• strong auth
• regular review

It detects permissions that remain but are no longer used or required.

Because privileged access and secret access are key concerns in regulated or enterprise environments.

ABAC (Attribute-Based Access Control) is an alternative or supplement to RBAC that uses attributes to decide access.

Kubernetes node authorization gives nodes limited access to API resources relevant to their operation.

Because nodes are not general users but workload hosts with special operational permissions.

Controllers use special service accounts with limited but specific permissions to reconcile resources.

A bound token is associated with a specific identity and can be short-lived or audience-scoped.

It reduces misuse if a token is used against the wrong API or service.

It verifies tokens and extracts identity information, used in external auth flows.

It allows administrators to test access decisions as another subject without changing credentials.

Because it can be used to test or bypass assumptions if not tightly controlled.

An audit log records API calls and access decisions, making RBAC actions traceable.

Because they help investigate suspicious behavior and prove what happened.

A policy engine applies additional rules beyond RBAC, such as admission policies or custom policy checks.

Policy-as-code defines access rules and security policies declaratively and version controllably.

Because policy-as-code can enforce organizational guardrails beyond simple RBAC roles.

A custom admission controller can inspect or reject API requests based on custom security policy.

They catch unsafe configurations before they reach the cluster.

RBAC decides whether access is allowed. Admission policy decides whether a resource configuration is acceptable.

A privileged workload is one with broad access or trust and thus higher risk if compromised.

Because different teams or workloads should not see or modify each other’s resources.

RBAC enforces identity, scope, and least privilege at the Kubernetes API boundary; the right design is explicit, namespaced, reviewed, and tied to real operational needs.