Skip to content

Kubernetes RBAC

Kubernetes RBAC (Role-Based Access Control) is a security mechanism used to regulate access to the Kubernetes API Server^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. It is an authorization method introduced in Kubernetes v1.8 that manages permissions based on roles assigned to users, groups, or service accounts^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

By dynamically configuring permissions via the rbac.authorization.k8s.io API group, administrators can enforce the principle of least privilege, ensuring subjects only have access necessary for their function^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Core Concepts

RBAC authorization is implemented through four primary object types: Role, ClusterRole, RoleBinding, and ClusterRoleBinding^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Role vs ClusterRole

Both Role and ClusterRole define a set of permission rules (Rules), but they differ in scope^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

  • Role: Grants permissions within a specific namespace^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
  • ClusterRole: A cluster-scoped resource that grants permissions across the entire cluster or at the cluster level^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

A Rule consists of three parts^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]: * apiGroups: The API group the resource belongs to (e.g., "" for core, apps, batch). * resources: The type of resource (e.g., pods, deployments, services). * verbs: The action allowed (e.g., get, list, watch, create, delete).

RoleBinding vs ClusterRoleBinding

A Binding connects a Subject (user, group, or service account) to a Role (or ClusterRole), effectively granting the defined permissions to that subject^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

  • RoleBinding: Grants permissions within a specific namespace^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
  • ClusterRoleBinding: Grants permissions cluster-wide^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Subjects

Subjects are the entities to which permissions are granted. They can be^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]:

  • User: A standard user (e.g., configured in kubeconfig or authenticated via X.509 certificate).
  • Service Account: Namespaced resource associated with pods for intra-cluster communication^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
  • Group: A collection of users. Kubernetes uses prefixes like system:serviceaccounts:<namespace> to group service accounts^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Verification

To verify if a user has specific permissions, kubectl provides the auth can-i command^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

# Check if the current user can create deployments in the default namespace
[kubectl auth can-i](<./kubectl-auth-can-i.md>) create deployments --namespace default

Authentication vs Authorization

RBAC handles Authorization (determining what an authenticated user can do), but it relies on Authentication to verify who the user is^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Authentication typically involves validating a user's identity via mechanisms like X.509 client certificates, tokens, or OpenID Connect^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. Once authenticated, the Kubernetes API Server uses RBAC to decide if the requested API operation is allowed^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

  • [[Authentication]]
  • [[Service Accounts]]
  • [[Kubernetes API Server]]

Sources