Overview

All API objects in Kubernetes are persisted in etcd, but every operation on these objects must go through the kube-apiserver. The API server acts as the gatekeeper for authorization, and Kubernetes uses RBAC (Role-Based Access Control) as its authorization mechanism.

Core RBAC Concepts

Three fundamental conecpts form the foundation of Kubernetes RBAC:

1. Role: A set of rules that defines permissions for Kubernetes API objects
2. Subject: The entity that receives permissions—can be a human user, machine, or ServiceAccount
3. RoleBinding: The connection between a subject and a role, granting the specified permissions

Role

A Role represents a collection of permissions (rules) for API operations. These permissions are additive—only allow rules exist, no deny rules. Roles are Kubernetes API objects scoped to a specific namespace.

Example

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

This Role grants permissions to perform GET, LIST, and WATCH operations on Pod objects within the production namespace. The apiGroups: [""] indicates the core API group.

RoleBinding

RoleBinding establishes the relationship between subjects and roles. It specifies which subjects receive which permissions. Like Roles, RoleBindings are namespace-scoped.

Example

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: production
  name: developer-pod-access
subjects:
- kind: User
  name: john-developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Kubernetes supports multiple authentication mechanisms. Users can be authenticated through external services like Keystone or through static username/password files configured for the API server.

ClusterRole and ClusterRoleBinding

For resources outside namespace scope (like Nodes) or when permissions should apply across all namespaces, ClusterRole and ClusterRoleBinding provide cluster-wide authorization.

Example

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: node-monitor
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ops-team-node-access
subjects:
- kind: User
  name: ops-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-monitor
  apiGroup: rbac.authorization.k8s.io

Available Verbs

Kubernetes supports these verbs for API operations:

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Fine-Grained Rules

Rules can target specific resources by name:

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["get", "update"]

This grants permissions only to the app-config ConfigMap.

ServiceAccount

While human users require external authentication, ServiceAccounts provide identity for workloads running in pods. Each namespace contains a default ServiceAccount automatically.

Creating a ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: production
  name: app-runner

Binding a ServiceAccount to a Role

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: app-reader-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-runner
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Pod Using ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  namespace: production
  name: api-client
spec:
  containers:
  - name: client
    image: curl:latest
  serviceAccountName: app-runner

When a pod uses a ServiceAccount, Kubernetes automatically mounts credentials in /var/run/secrets/kubernetes.io/serviceaccount/. This directory contains:

• ca.crt: Certificate authority for API server verification
• namespace: The pod's namespace
• token: Authentication token for API requests

The mounted token allows the container to authenticate to the API server with the ServiceAccount's identity. The actual permissions are determined by the RoleBindings associated with that ServiceAccount.

Default ServiceAccount Behavior

Pods without an explciit serviceAccountName automatically receive the namespace's default ServiceAccount. This default account has broad API access by default. Production environments should create restrictive RoleBindings for the default ServiceAccount or replace it with a limited alternative.

Summary

The most common pattern in Kubernetes uses ServiceAccounts with RoleBindings to control pod access to the API server. This approach is essential when deploying controllers, operators, and custom integrations.