Module 4 of 16

Kubernetes Authentication & Authorization

Service accounts, OIDC, RBAC deep dive, and identity in distributed systems

3 hours2 labsFree

Watch as Slides Course overview Lab code

Start here

Learning objectives

Configure Kubernetes authentication methods
Design least-privilege RBAC policies
Integrate OIDC for human authentication
Debug authentication and authorization failures

Authentication proves who is making a request. Authorization decides what they can do. In Kubernetes, these are separate subsystems that run in sequence on every API request.

Kubernetes Authentication Methods

Service Account Tokens: Projected tokens for pods (auto-mounted by default). Short-lived since K8s 1.24.
OIDC: External identity providers (Okta, Auth0, Dex) for human users. Recommended for developer access.
X.509 Client Certificates: Certificate-based auth for system components and CI/CD. Hard to revoke.
Webhook Token Authentication: Custom auth server for specialized flows.

RBAC Design Principles

# Principle 1: Namespace-scoped Roles over ClusterRoles
# Principle 2: Bind to specific ServiceAccounts, not groups
# Principle 3: Use verb restrictions (get,list vs create,delete)
# Principle 4: Audit with: kubectl auth can-i --list --as=system:serviceaccount:ns:sa

Identity in Distributed Systems

Kubernetes service accounts provide in-cluster identity. But what about services communicating across clusters? Or between Kubernetes and VMs? This is where SPIFFE (Module 6) bridges the gap — providing portable, cryptographic workload identity beyond Kubernetes boundaries.

Real world

Where this shows up

OIDC integration for developer kubectl access
Service account token audit and cleanup
Cross-cluster identity challenges
Debugging auth failures in production

Common mistakes

What usually breaks

Using cluster-admin for CI/CD service accounts
Not disabling auto-mounting of service account tokens
Granting list secrets permission without understanding the blast radius
Using X.509 certificates for human users (impossible to revoke without CA rotation)

Key terms

Vocabulary used in this module

OIDC

OpenID Connect — federated identity protocol for single sign-on

RBAC

Role-Based Access Control — maps roles to permissions to subjects

Service Account

Kubernetes identity for pods, used for API server authentication

Projected Token

Short-lived, audience-bound service account token (K8s 1.24+)

Labs

Hands-on labs

35 minIntermediate

Configure OIDC Authentication

Integrate an OIDC provider for human user authentication.

Deploy Dex as an OIDC provider
Configure the API server to trust Dex
Authenticate with kubectl using OIDC tokens
Verify identity with kubectl auth whoami

View lab on GitHub

25 minBeginner

Debug Authorization Failures

Troubleshoot RBAC denials systematically.

Create a restricted service account
Attempt unauthorized operations and observe errors
Use kubectl auth can-i to diagnose permissions
Fix RBAC bindings and verify access

View lab on GitHub

Recap

Key takeaways

Authentication and authorization are separate — never confuse them
Use OIDC for human users, service accounts for workloads
RBAC should be namespace-scoped and least-privilege by default
Audit permissions regularly with kubectl auth can-i
Kubernetes identity ends at the cluster boundary — SPIFFE extends it

Related resources