Module 4: Kubernetes Authentication & Authorization

Learning Objectives

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

Why This Matters

RBAC misconfigurations are the #1 cause of Kubernetes privilege escalation. Every production cluster needs well-designed authentication and authorization — this module teaches you to build it right from the start.

Lesson Content

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 Use Cases

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

Common Mistakes

• 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)

Production Story

A company using X.509 client certificates for developer access could not revoke a terminated employee access without rotating the entire CA — disrupting all 50 developers. After switching to OIDC via Dex, revocation was instant via the identity provider.

Career Relevance

Authentication and authorization design is fundamental to every Kubernetes security architecture. Engineers who understand the full auth flow are essential for platform teams.

Key Terms

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+)

Hands-On Labs

1. Configure OIDC Authentication

   Integrate an OIDC provider for human user authentication.

   35 min - Intermediate

   • 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 files on GitHub

2. Debug Authorization Failures

   Troubleshoot RBAC denials systematically.

   25 min - Beginner

   • 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 files on GitHub

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