CKA Day 22 — Kubernetes Authentication and Authorization Simply Explained

Day 22 of the Tech Tutorials with Piyush 40-day CKA course. A 20-minute deep-dive into how Kubernetes decides who you are (authentication) and what you can do (authorization), plus the kubeconfig file that ties it all together.

Key Takeaways

Authentication vs Authorization — Authentication verifies identity (who are you?). Authorization verifies permissions (what can you do?). In Kubernetes, every API request passes through both gates before reaching the resource.

Authentication Methods — Kubernetes supports multiple authentication plugins: X.509 client certificates, bearer tokens (static, service account, OIDC), basic auth (deprecated), and webhook token authentication. The API server delegates identity verification to the configured plugin, then extracts the username, UID, groups, and extra fields into a UserInfo object that downstream authorizers consume.

Authorization Modes — Kubernetes implements four authorization modules that can be stacked (checked in order until one allows or denies):

1. Node Authorization — Grants kubelet permissions scoped to the node it runs on (e.g., read Pods bound to its node, write node status). Enabled by default.
2. ABAC (Attribute-Based Access Control) — Legacy policy files (--authorization-policy-file). Evaluates rules based on user attributes, resource attributes, and environment. Difficult to manage at scale and rarely used in modern clusters.
3. RBAC (Role-Based Access Control) — The modern standard. Uses Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects to grant permissions. Namespace-scoped for Roles; cluster-wide for ClusterRoles. The CKA exam focuses heavily on RBAC.
4. Webhook Authorization — Delegates authorization decisions to an external HTTP service (e.g., Open Policy Agent). Useful for centralized policy enforcement across clusters.

Kubeconfig File — The client-side credential bundle that tells kubectl how to connect and authenticate. It contains three sections: clusters (API server endpoints and CA certificates), users (client certificates, tokens, or basic auth), and contexts (a named tuple of cluster + user + namespace). The current-context field determines which cluster kubectl talks to by default. CKA exam tasks frequently require editing or switching contexts with kubectl config use-context.

Practical Demo — The video demonstrates creating a new user (via client certificate), configuring a kubeconfig context for that user, and then testing access with kubectl auth can-i to verify RBAC permissions.

See Also

Wiki Concepts

• Kubernetes Authentication & Authorization — the two-gate security model: authn → authz
• Kubernetes RBAC — Roles, ClusterRoles, Bindings, and the CKA YAML patterns
• Kubernetes Kubeconfig — clusters, users, contexts, and imperative config commands
• Kubernetes Architecture — how the API server processes requests through authn/authz
• Kubernetes Namespaces — RBAC scope boundaries and namespace-scoped vs cluster-scoped resources
• TLS Fundamentals — X.509 client certificates used for Kubernetes authentication

Related Sources

• CKA Day 21 — Manage TLS Certificates In a Kubernetes Cluster — prerequisite for client certificate authentication

Creator / Entity

• Tech Tutorials with Piyush — creator of the 40daysofKubernetes CKA series