L4. Authentication: Certificates, OIDC and Service Accounts

No Built-in User Database

Kubernetes does not store user accounts. Instead, it delegates authentication to external systems. The API server verifies the identity presented in each request and extracts a username and group membership. Authorization (RBAC) then decides what that identity can do.

X.509 Client Certificates

The most common authentication method for cluster administrators. The API server trusts a Certificate Authority (CA) and any client presenting a certificate signed by that CA is authenticated.

The certificate's Common Name (CN) becomes the username, and Organization (O) fields become group memberships:

openssl req -new -key admin.key -out admin.csr \
  -subj "/CN=admin-user/O=system:masters"

Best practice: Avoid system:masters for day-to-day operations. This group has irrevocable cluster-admin privileges that cannot be restricted by RBAC. Use it only for break-glass scenarios.

OIDC Integration

For production environments with multiple users, integrate the API server with an OIDC provider (Entra ID, Okta, Google Workspace). This gives you centralized identity, MFA, and session management.

Configure the API server with:

--oidc-issuer-url=https://login.microsoftonline.com/<tenant>/v2.0
--oidc-client-id=<app-id>
--oidc-username-claim=email
--oidc-groups-claim=groups

On managed clusters, OIDC integration is configured through the provider's console:

• EKS: Use IAM identity mapping or EKS access entries
• AKS: Enable Entra ID integration in cluster settings
• GKE: Use Google Groups for RBAC or Workforce Identity Federation

Service Accounts

Service accounts are Kubernetes-native identities for workloads. Every pod runs under a service account. If you do not specify one, Kubernetes assigns the default service account in the namespace.

Key changes in modern Kubernetes (v1.24+):

• Token projection: Service account tokens are time-limited, audience-bound, and not stored as secrets
• No auto-mount: Set automountServiceAccountToken: false on service accounts or pods that do not need API access
• Bound tokens: Tokens are bound to a specific pod and expire when the pod is deleted

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
automountServiceAccountToken: false

Authentication Best Practices

1. Never use static token files or basic auth in production
2. Integrate OIDC for human users with MFA enforcement
3. Use short-lived certificates (hours, not years) for admin access
4. Disable default service account token mounting in namespaces where pods do not need API access
5. Audit authentication failures in API server logs to detect credential stuffing or brute force