KCSA — Authentication Methods

6 minute read

Authentication — “Who Are You?”

Authentication (often abbreviated authn) is the process of verifying the identity of a client making a request to the Kubernetes API server. Before the API server checks whether a request is allowed, it first determines who is asking.

Every request to the API server is either:

  • Authenticated — associated with a known user or service account.
  • Anonymous — treated as the system:anonymous user if anonymous auth is enabled.

Kubernetes does not have a built-in user database. It relies entirely on external identity sources — certificates, tokens, and identity providers.

KCSA Relevance: Authentication is a core topic under the “Kubernetes Cluster Security” domain (22 %). Expect questions about which authentication method is appropriate for a given scenario.

Authentication Methods at a Glance

Method Use Case Security Level Notes
X.509 Client Certificates Cluster components, admin kubectl High kubeadm default for cluster bootstrap
Bearer Tokens Service accounts, bootstrap Medium Static tokens are deprecated
OIDC Tokens Human users via IdP High Recommended for user authentication
Webhook Token Auth Custom identity integration High Delegates validation to external service
Bootstrap Tokens Node joining Low (temporary) Short-lived by design

Let’s examine each method in detail.

X.509 Client Certificates

X.509 client certificate authentication is the most common method for cluster components and administrator access.

How It Works

  1. The client presents a TLS client certificate signed by the cluster’s Certificate Authority (CA).
  2. The API server validates the certificate against the configured --client-ca-file.
  3. The Common Name (CN) becomes the username; the Organization (O) fields become group memberships.

Example Certificate Identity

Subject: CN=jane, O=developers, O=qa-team

This maps to:

  • Username: jane
  • Groups: developers, qa-team

Where You See It

  • kubeadm generates client certificates for kube-controller-manager, kube-scheduler, and the initial admin kubeconfig.
  • The kubelet uses a client certificate to authenticate to the API server.

Strengths and Weaknesses

Strength Weakness
Mutual TLS — strong cryptographic identity No built-in revocation (requires CRL or short-lived certs)
No external dependency at runtime Certificate rotation can be complex
Works offline Cannot easily add/remove users without new certs

Exam Tip: If a question asks how kubeadm clusters authenticate components by default, the answer is X.509 client certificates.

Bearer Tokens

Bearer tokens are passed in the Authorization: Bearer <token> HTTP header.

Types of Bearer Tokens

1. Static Token File (Deprecated)

The API server can read tokens from a CSV file specified via --token-auth-file.

token,user,uid,"group1,group2"

Why static tokens are deprecated:

  • No expiration — tokens live forever unless the file is manually updated.
  • Stored in plaintext on the control plane node.
  • Requires API server restart to add or remove tokens.
  • No audit trail for token creation or distribution.

2. Service Account Tokens

Every pod in Kubernetes can receive a service account token. These are JWT tokens signed by the API server’s service account signing key.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: app
      image: my-app:1.0

The token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token (unless disabled).

We cover service account tokens in depth in the Service Accounts & Token Security topic.

OIDC Tokens (OpenID Connect)

OIDC is the recommended method for authenticating human users to Kubernetes.

The OIDC Flow

┌──────────┐     1. Login      ┌──────────────┐
│   User   │ ───────────────► │ Identity      │
│ (kubectl)│                   │ Provider (IdP)│
│          │ ◄─────────────── │ (Keycloak,    │
│          │  2. id_token +    │  Dex, Azure   │
│          │     refresh_token │  AD, Okta)    │
└────┬─────┘                   └──────────────┘
     │
     │ 3. API request with
     │    Authorization: Bearer <id_token>
     ▼
┌──────────────┐
│  API Server  │  4. Validates JWT signature
│              │     using IdP's public keys
│              │  5. Extracts username + groups
│              │     from token claims
└──────────────┘

How the API Server Validates OIDC Tokens

  1. The API server is configured with the IdP’s issuer URL and client ID.
  2. It fetches the IdP’s public keys from the OIDC discovery endpoint.
  3. When a request arrives with a JWT, it validates the signature, issuer, audience, and expiration.
  4. The configured claims are mapped to a Kubernetes username and groups.

API Server OIDC Flags

Flag Purpose Example
--oidc-issuer-url IdP issuer URL https://keycloak.example.com/realms/k8s
--oidc-client-id Expected audience kubernetes
--oidc-username-claim Claim to use as username email
--oidc-groups-claim Claim to use as groups groups
--oidc-username-prefix Prefix to prevent conflicts oidc:
--oidc-groups-prefix Group prefix oidc:
  • Short-lived tokens — JWTs have expiration times.
  • Centralized identity — users managed in one IdP across many clusters.
  • No secrets on the API server — tokens are validated using public keys.
  • Standard protocol — works with any OIDC-compliant identity provider.

Exam Tip: OIDC is the recommended way to authenticate human users. The API server never contacts the IdP directly during token validation — it uses the IdP’s cached public keys.

Webhook Token Authentication

Webhook token authentication delegates token validation to an external service.

How It Works

  1. The API server receives a bearer token.
  2. It sends the token to a configured webhook endpoint as a TokenReview request.
  3. The webhook service validates the token and returns the user info.

API Server Configuration

--authentication-token-webhook-config-file=/etc/kubernetes/webhook-config.yaml

When to Use Webhook Auth

  • Integration with proprietary identity systems.
  • Custom token validation logic.
  • Organizations that need to validate tokens against a centralized service.

Bootstrap Tokens

Bootstrap tokens are used exclusively during cluster setup and node joining.

Characteristics

  • Format: [a-z0-9]{6}.[a-z0-9]{16} (e.g., abcdef.0123456789abcdef)
  • Stored as Secrets in the kube-system namespace.
  • Short-lived — have a built-in TTL.
  • Used by kubeadm join to authenticate new nodes.

Security Properties

Property Value
Default TTL 24 hours
Namespace kube-system
Authenticated as system:bootstrap:<token-id>
Group system:bootstrappers

Never use bootstrap tokens for ongoing authentication. They exist only to bootstrap trust during cluster setup.

Anonymous Authentication

By default, the Kubernetes API server allows anonymous requests.

  • Anonymous requests are authenticated as user system:anonymous in group system:unauthenticated.
  • RBAC policies determine what anonymous users can access (usually very little).
  • Can be disabled with --anonymous-auth=false.

When Anonymous Auth Is Needed

  • Health check endpoints (/healthz, /readyz, /livez) are often accessed without credentials.
  • RBAC discovery — some clusters allow anonymous users to list API resources.

Security Consideration

If RBAC is not properly configured, anonymous authentication can expose sensitive information. Always audit what permissions system:unauthenticated has.

Authentication Strategy Decision Table

Use this table to determine which authentication method fits each scenario:

Scenario Recommended Method Why
Cluster component (kubelet, scheduler) X.509 Client Certificates Strong identity, no external dependency
Human user (developer, operator) OIDC via IdP Centralized, short-lived tokens, SSO
Pod accessing the API server Service Account Token (projected) Bound to pod identity, auto-rotated
New node joining the cluster Bootstrap Token Temporary, purpose-built
Custom enterprise identity system Webhook Token Auth Delegates to existing infrastructure
CI/CD pipeline Service Account Token Scoped permissions, automatable

Multiple Authentication Methods

The API server can be configured with multiple authentication methods simultaneously. When a request arrives:

  1. Each enabled authenticator tries to authenticate the request in order.
  2. The first authenticator to succeed determines the identity.
  3. If no authenticator succeeds, the request is treated as anonymous (if enabled) or rejected.

A typical production cluster enables:

  • X.509 client certificates (for components)
  • OIDC (for human users)
  • Service account tokens (for pods)

These three work together without conflict because they authenticate different types of clients.

What the API Server Receives After Authentication

After successful authentication, the API server knows:

Attribute Source Example
Username CN from cert, email from OIDC, system:serviceaccount:ns:name
UID Unique identifier (optional)
Groups O from cert, groups claim from OIDC, system:serviceaccounts
Extra fields Additional key-value pairs from authenticators

This identity information is then passed to the authorization layer (covered in the RBAC and Authorization Modes topics).

Key Takeaways for the Exam

Concept What to Remember
X.509 Certificates Default for cluster components; CN = user, O = groups
Static Tokens Deprecated — no expiry, plaintext, requires restart
OIDC Recommended for human users; validated via public keys
Service Account Tokens For pods; prefer projected (time-bound) tokens
Bootstrap Tokens Node joining only; short-lived
Anonymous Auth Enabled by default; system:anonymous user
Multiple Methods API server tries each authenticator in order
No User Database Kubernetes relies entirely on external identity sources

What’s Next?

Now that you understand how Kubernetes verifies identity, the next topic covers what authenticated users are allowed to do.

Role-Based Access Control (RBAC)

Updated:

You may also enjoy