Master Kubernetes RBAC in One Article: A Complete Overview

Understanding RBAC Authentication and Authorization in Kubernetes

Overview

Kubernetes ensures cluster security through authentication, authorization, and admission control. Official documentation can be found at the Kubernetes website.

Authentication Account Types

User accounts – for human users.

Service accounts – for pods.

Groups – to group users or service accounts for unified permission policies.

Authentication Methods

HTTP Basic Authentication

Credentials are sent as a Base64‑encoded "username:password" string in the HTTP Authorization header.

HTTP Token Authentication

A long, unguessable token represents a user. The token is placed in the HTTP header and matched against stored tokens.

HTTPS (Mutual TLS) Authentication – Recommended

Uses CA‑signed client certificates for the highest security, though it is the most complex to set up.

Authorization Management Methods

AlwaysDeny – denies all requests (useful for testing).

AlwaysAllow – allows all requests (default Kubernetes behavior).

ABAC – attribute‑based access control.

Webhook – calls an external REST service for authorization decisions.

Node – special mode for kubelet requests.

RBAC – role‑based access control (default with kubeadm).

RBAC Introduction

RBAC (Role‑Based Access Control) defines which subjects are granted which permissions.

Objects: User, Group, ServiceAccount.

Roles: a set of permissions on resources.

Bindings: associate a role with subjects.

Role Details

A Role defines permissions within a single namespace.

Role Manifest Example

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: develop-role
rules:
- apiGroups: ["", "apps"]
  resources: ["pods","deployments"]
  verbs: ["get","list"]
- apiGroups: ["", "apps"]
  resources: ["configmaps","secrets","daemonsets"]
  verbs: ["get","list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["delete","create"]

Key fields:

apiGroups : API group identifiers (e.g., "" for core, "apps" for deployments).

resources : Resource types (pods, deployments, etc.).

verbs : Allowed actions (get, list, create, delete, etc.).

resourceNames (optional): Specific resource names.

nonResourceURLs (optional, only for ClusterRole): Non‑resource endpoints.

Role Practical Commands

# Apply the Role
kubectl apply -f role-default.yaml
# List Roles
kubectl get role -o wide
# Describe a Role
kubectl describe role custom-role

ClusterRole Details

A ClusterRole defines permissions at the cluster level or across all namespaces.

ClusterRole Manifest Example

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-clusterrole
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","list","watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
  resourceNames: ["backend"]
- nonResourceURLs: ["/healthz","/metrics"]
  verbs: ["get"]

Default ClusterRoles include admin, cluster-admin, edit, and view, each with progressively broader permissions.

RoleBinding Details

RoleBinding

binds a Role (or a ClusterRole) to subjects within a namespace.

RoleBinding Manifest Example

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-rolebinding
  namespace: dev-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: developer
subjects:
- kind: User
  name: alice
  apiGroup: ""
- kind: ServiceAccount
  name: my-app-sa
  namespace: dev-namespace
- kind: Group
  name: my-group
  apiGroup: ""

Key fields:

metadata.namespace : Target namespace.

roleRef : References the Role or ClusterRole.

subjects : List of users, groups, or service accounts to bind.

ClusterRoleBinding Details

ClusterRoleBinding

binds a ClusterRole to subjects across the entire cluster.

ClusterRoleBinding Manifest Example

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: admin-user
  apiGroup: ""
- kind: Group
  name: system:serviceaccounts
  apiGroup: ""

Key fields:

metadata.name : Unique name for the binding.

roleRef : Must reference a ClusterRole.

subjects : Users, groups, or service accounts granted the cluster‑wide permissions.

Differences Between Role and ClusterRole

Scope : Role – single namespace; ClusterRole – all namespaces or cluster‑level resources.

Definition : Role includes metadata.namespace; ClusterRole does not.

Resources : Role – namespace resources only; ClusterRole – namespace resources, cluster resources (Nodes, Namespaces), and non‑resource URLs.

Binding : Role is bound via RoleBinding; ClusterRole can be bound via RoleBinding (within a namespace) or ClusterRoleBinding (cluster‑wide).

Typical Use Cases : Role – grant developers permissions in their own namespace; ClusterRole – grant administrators full cluster access or enable cross‑namespace operations.

Differences Between RoleBinding and ClusterRoleBinding

Scope : RoleBinding – single namespace; ClusterRoleBinding – cluster‑wide.

Role Type : RoleBinding can reference a Role or a ClusterRole (if the ClusterRole’s rules are namespace‑compatible); ClusterRoleBinding only references a ClusterRole.

Definition Location : RoleBinding is a namespaced resource; ClusterRoleBinding is a cluster‑scoped resource.

Typical Scenarios : RoleBinding – grant users access to resources in a specific namespace; ClusterRoleBinding – grant administrators or service accounts cluster‑wide privileges, such as managing nodes or viewing all pods.

RoleBinding vs. ClusterRoleBinding: RoleBinding ties permissions to a namespace, while ClusterRoleBinding applies permissions across the entire cluster.