Understanding Kubernetes Authentication and Authorization Models

Learn how Kubernetes verifies user identities and determines their permissions before granting access to the cluster API.

In this lesson, you will learn how Kubernetes verifies who you are (Authentication) and what you are allowed to do (Authorization) when you interact with the cluster API.

Every request made to the Kubernetes API server goes through a two-gate security process. Think of it like entering a high-security building: first, you show your ID to prove you are who you say you are; second, you show your clearance badge to prove which rooms you are allowed to enter.

1. Authentication (The "Who")

Kubernetes does not have an internal database of users. Instead, it relies on external sources to verify identities. Common methods include:

X.509 Client Certificates: A trusted CA signs your certificate, which the API server validates.
Service Accounts: Used by pods to interact with the API (e.g., system:serviceaccount:default:my-operator).
OpenID Connect (OIDC): Tokens issued by providers like Google or Okta.

Once the API server verifies the identity, it extracts the username and the groups the user belongs to.

2. Authorization (The "What")

Once your identity is confirmed, Kubernetes checks your permissions. The primary mechanism here is Role-Based Access Control (RBAC). RBAC uses two main resources:

Roles/ClusterRoles: Define what can be done (e.g., get, list, create on pods).
RoleBindings/ClusterRoleBindings: Grant these permissions to a specific user or service account.

For example, an operator might have a ClusterRole that allows it to manage custom resources:

rules:
- apiGroups: ["my.api.group"]
  resources: ["my-crds"]
  verbs: ["get", "list", "watch", "update"]

If you attempt an action that isn't explicitly permitted by a binding, the API server rejects the request with a 403 Forbidden error. This "deny-by-default" strategy ensures that even if you are authenticated, you cannot accidentally or maliciously modify resources outside your defined scope. By decoupling identity management from access policy, Kubernetes keeps the cluster secure and flexible for enterprise environments.

Key Takeaway: Kubernetes separates identity verification (Authentication) from permission enforcement (Authorization), relying on external providers for the former and RBAC policies for the latter.