Master Kubernetes Authentication & Authorization: From Users to RBAC

Kubernetes exposes its API via the API Server; without proper security, requests can be abused and the entire cluster may collapse.

Kubernetes provides authentication (who you are) and authorization (what you can do) to protect the cluster.

Authentication

Authentication determines whether a user can log in to Kubernetes and send requests to the API Server.

There are two user categories:

Normal Users – external users

Service Accounts – internal users managed by Kubernetes

Normal Users

Normal Users are external to Kubernetes and can include administrators with private keys, third‑party providers (e.g., Google Accounts), or username/password files.

Kubernetes authenticates them via certificates; any user presenting a valid certificate is accepted.

The certificate’s CN becomes the username and the Organization becomes the group, which are then matched to a Role for permissions.

Service Accounts

Service Accounts are created in a specific namespace, either automatically by the API Server or via

kubectl

. When a Service Account is created, a Secret containing its token is generated (pre‑1.24) or a token is issued on pod creation (post‑1.24). Pods using a Service Account mount this token, enabling API access.

Authentication Strategies

Client certificates

Bearer tokens

Authentication proxy

HTTP basic auth via plugin

When an HTTP request reaches the API Server, it includes:

Username

UID

Groups

Extra fields

If multiple authentication methods are enabled, the first successful one is used.

Client Certificate

Provide a valid certificate via

--client-ca-file=SOMEFILE

. The certificate’s Subject CN becomes the username and the Organization becomes the group.

Bearer Token

The API Server expects an

Authorization: Bearer <token>

header. Tokens can be sourced from:

Static token file

Service Account tokens

OpenID Connect (OIDC) tokens

Static Token File

Specify

--token-auth-file=SOMEFILE

to load a CSV of usernames and groups.

Service Account Tokens

Before v1.24, a Secret stores the token; after v1.24, the token is generated on pod startup via the TokenRequest API.

OpenID Connect Tokens

OIDC uses OAuth2; the ID token is used as a bearer token. The flow includes logging into the identity provider, obtaining access, ID, and refresh tokens, passing the ID token to

kubectl

, which sends it in the Authorization header, and the API Server validates the JWT signature and expiration before authorizing the request.

Authentication alone does not grant permissions; authorization follows.

Authorization

Authorization Flow

After authentication, the API Server checks whether the request is permitted to access the requested resource. If any enabled authorizer denies the request, it is rejected with a 403 error.

The API Server evaluates policies based on user, group, extra fields, API resource, request path, verb, namespace, and API group.

Authorization Modules

Node

ABAC

RBAC

Webhook

This article focuses on RBAC, the most commonly used model.

RBAC Concepts

Rule – a set of API groups and verbs

Role – a namespace‑scoped collection of rules

ClusterRole – a cluster‑wide collection of rules

Subject – a user, group, or Service Account

RoleBinding – binds a Role to subjects within a namespace

ClusterRoleBinding – binds a ClusterRole to subjects cluster‑wide

Role and ClusterRole

Roles define permissions for a specific namespace; ClusterRoles apply cluster‑wide. Example Role YAML:

<code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
- apiGroups: [""]
  resources: ["pods","deployment"]
  verbs: ["create","delete","watch","list","get"]
</code>

Example ClusterRole YAML:

<code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role-demo
rules:
- apiGroups: [""]
  resources: [""]
  verbs: ["watch","list","get"]
</code>

RoleBinding and ClusterRoleBinding

RoleBinding links a Role to subjects (User, Group, ServiceAccount) within a namespace. Example:

<code>apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: joker-rolebinding
  namespace: devops
subjects:
- kind: User
  name: joker
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io
</code>

ClusterRoleBinding works similarly but is cluster‑wide.

<code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: joker-clusterrolebinding
subjects:
- kind: User
  name: joker
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-role-demo
  apiGroup: rbac.authorization.k8s.io
</code>

Service Account

Service Accounts provide identity for pods. Example ServiceAccount definition:

<code>apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: devops
  name: sa-demo
</code>

Bind it to a Role:

<code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
- apiGroups: [""]
  resources: ["pods","deployment"]
  verbs: ["create","delete","watch","list","get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-rolebinding
  namespace: devops
subjects:
- kind: ServiceAccount
  name: sa-demo
  namespace: devops
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io
</code>

Creating a pod with this Service Account mounts its token at

/var/run/secrets/kubernetes.io/serviceaccount

, enabling the pod to call the API Server.