Skip to content

6.02 Kubernetes Authentication

1️⃣ Overview

A Kubernetes cluster consists of:

  • Multiple nodes (physical or virtual)
  • Control plane components (API server, etcd, scheduler, controller manager)
  • Users and services interacting with the cluster

Who Accesses the Cluster?

Type Examples Managed By
Humans Admins, Developers External Identity System
Robots CI/CD, Controllers, Apps Service Accounts
End Users Application Users Application Itself

Note

Kubernetes authentication focuses on cluster access, not end users of deployed applications.

2️⃣ User Types in Kubernetes

👤 Human Users

  • Administrators
  • Developers
  • Platform Engineers

⚠ Kubernetes does NOT manage human users natively.

You cannot:

kubectl create user user1   # ❌ Not valid
kubectl list users          # ❌ Not valid

Kubernetes relies on:

  • Certificates
  • External identity providers
  • Token files (not recommended in production)

🤖 Service Accounts (Managed by Kubernetes)

Service accounts are used by:

  • Pods
  • Controllers
  • CI/CD tools
  • Automation systems 
kubectl create serviceaccount sa1
kubectl get serviceaccount

Success

Service Accounts are first-class Kubernetes objects and are fully managed via the API.

3️⃣ Authentication Flow

All requests go through the kube-apiserver:

  1. Client (kubectl / curl / automation tool)
  2. kube-apiserver
  3. Authentication
  4. Authorization
  5. Request processing 
kubectl get pods

Or direct API call:

curl https://<api-server>:6443

Note

Authentication happens before authorization (RBAC).

4️⃣ Authentication Mechanisms

🔹 1. Static Token File (Basic & Insecure)

CSV format:

<token>,<username>,<uid>,<group>

Example:

KpjCVbI7rCFAHYPkBzRb7gu1cUc4B,user10,u0010,group1

API server configuration:

--token-auth-file=/path/user-token-details.csv

Authentication request:

curl -k https://<master-ip>:6443/api/v1/pods --header "Authorization: Bearer KpjCVbI7rCFAHYPkBzRb7gu1cUc4B"

Danger

Static token files store credentials in plain text.

  • ❌ Not recommended for production
  • ❌ No rotation mechanism
  • ❌ Requires API server restart

Users authenticate using:

  • Client certificate
  • Private key
  • Signed by cluster CA 
kubectl --client-certificate=user.crt --client-key=user.key get pods

Success

This is the standard production method for admin access.

🔹 3. Identity Providers (Production Grade)

Enterprise-ready authentication via:

  • LDAP
  • Active Directory
  • OIDC
  • Kerberos
  • Cloud IAM providers

Configured via API server flags:

--oidc-issuer-url=
--oidc-client-id=

Tip

In production, use OIDC with your corporate identity provider.

5️⃣ Production Best Practices

✅ DO

Success

  • Use OIDC or external identity provider
  • Use certificate-based authentication for admins
  • Use Service Accounts for workloads
  • Enable RBAC
  • Rotate certificates regularly
  • Enable audit logging
  • Use short-lived tokens
  • Store secrets securely (never in Git)

❌ DON'T

Danger

  • Do NOT use static password/token files in production
  • Do NOT store credentials in clear text
  • Do NOT share kubeconfig files
  • Do NOT grant cluster-admin to everyone
  • Do NOT disable TLS verification
  • Do NOT use long-lived service account tokens without rotation

🎯 Key Takeaways

  • Kubernetes does not manage human users internally
  • All authentication happens at kube-apiserver
  • Static token files are for learning only
  • Production should use:
  • Certificates
  • OIDC / Identity provider
  • RBAC enforcement

Quote

Secure the API server first. Everything in Kubernetes depends on it.