How Does User Authentication Work in Kubernetes and How Does It Relate to RBAC?

Detailed Answer

Kubernetes separates authentication (who are you?) from authorization (what can you do?). RBAC handles authorization, but it depends on authentication to provide the identity it evaluates. Understanding both is essential.

The Request Pipeline

Every API request passes through this chain:

Client Request
    │
    ▼
Authentication  ──→  Who is this? (username, groups, UID)
    │
    ▼
Authorization   ──→  Can they do this? (RBAC evaluation)
    │
    ▼
Admission       ──→  Any extra rules? (webhooks, policies)
    │
    ▼
Persistence     ──→  Write to etcd

If authentication fails, the request is rejected with 401 Unauthorized before RBAC is ever consulted.

Authentication Methods

Kubernetes supports multiple authentication strategies simultaneously. The API server tries each configured authenticator and accepts the first one that succeeds.

1. X.509 Client Certificates

The most common method for cluster administrators and CI/CD systems. The certificate's subject fields map to Kubernetes identity:

• Common Name (CN) becomes the username
• Organization (O) becomes the group(s)

# Generate a certificate for user "jane" in group "dev-team"
openssl genrsa -out jane.key 2048

openssl req -new -key jane.key -out jane.csr \
  -subj "/CN=jane/O=dev-team"

# Sign with the cluster CA
openssl x509 -req -in jane.csr \
  -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial \
  -out jane.crt -days 365

# Configure kubeconfig
kubectl config set-credentials jane \
  --client-certificate=jane.crt \
  --client-key=jane.key

kubectl config set-context jane-context \
  --cluster=my-cluster \
  --user=jane \
  --namespace=development

kubectl config use-context jane-context

RBAC can now match this identity:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-access
  namespace: development
subjects:
  # Match by username (from CN)
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
  # Or match by group (from O)
  - kind: Group
    name: dev-team
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

2. OpenID Connect (OIDC)

OIDC is the recommended method for production clusters because it integrates with existing identity providers (Okta, Azure AD, Google, Keycloak).

# API server flags for OIDC
--oidc-issuer-url=https://accounts.google.com
--oidc-client-id=my-k8s-cluster
--oidc-username-claim=email
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:

With these settings, a user authenticated via OIDC with email jane@company.com and groups ["engineering", "sre"] appears to RBAC as:

• Username: oidc:jane@company.com
• Groups: oidc:engineering, oidc:sre

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sre-access
  namespace: production
subjects:
  - kind: Group
    name: "oidc:sre"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

3. Webhook Token Authentication

For custom authentication systems, the API server can call an external webhook to validate bearer tokens:

# API server flag
--authentication-token-webhook-config-file=/etc/kubernetes/webhook-config.yaml

# webhook-config.yaml
apiVersion: v1
kind: Config
clusters:
  - name: auth-service
    cluster:
      server: https://auth.internal.example.com/authenticate
      certificate-authority: /etc/kubernetes/auth-ca.crt
users:
  - name: apiserver
    user:
      client-certificate: /etc/kubernetes/apiserver-auth-client.crt
      client-key: /etc/kubernetes/apiserver-auth-client.key
contexts:
  - context:
      cluster: auth-service
      user: apiserver
    name: default
current-context: default

The webhook receives a TokenReview and returns the authenticated username and groups.

4. ServiceAccount Tokens

ServiceAccounts are the only identity type that Kubernetes manages natively. The API server validates projected ServiceAccount tokens directly:

Username: system:serviceaccount:<namespace>:<name>
Groups:   system:serviceaccounts
          system:serviceaccounts:<namespace>

Authentication vs Authorization Comparison

| Aspect | Authentication | Authorization (RBAC) | |---|---|---| | Question answered | "Who are you?" | "Are you allowed?" | | Error code | 401 Unauthorized | 403 Forbidden | | Configured where | API server flags | Role/ClusterRole + Bindings | | Manages users | External systems | Does not manage users | | Kubernetes objects | ServiceAccount only | Role, ClusterRole, RoleBinding, ClusterRoleBinding |

Managed Kubernetes Authentication

Cloud providers integrate their IAM systems:

AWS EKS:

# aws-auth ConfigMap maps IAM roles/users to Kubernetes identities
kubectl -n kube-system get configmap aws-auth -o yaml

mapRoles:
  - rolearn: arn:aws:iam::123456789:role/DevTeam
    username: dev-team-member
    groups:
      - dev-team

GKE:

# Google Cloud IAM identities are used directly
# Bind using the Google email address
kubectl create clusterrolebinding admin-binding \
  --clusterrole=cluster-admin \
  --user=admin@company.com

AKS:

# Azure AD integration
# Groups from Azure AD are available as RBAC subjects
kubectl create rolebinding team-access \
  --clusterrole=edit \
  --group=<azure-ad-group-object-id> \
  -n team-namespace

CertificateSigningRequest API

Since Kubernetes 1.18, you can use the CertificateSigningRequest API to issue certificates without direct CA access:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: jane-csr
spec:
  request: <base64-encoded-csr>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
    - client auth

# Approve the CSR
kubectl certificate approve jane-csr

# Retrieve the signed certificate
kubectl get csr jane-csr -o jsonpath='{.status.certificate}' | base64 -d > jane.crt

Best Practices

1. Use OIDC for human users — it integrates with SSO, supports MFA, and tokens can be short-lived and revoked.
2. Use certificates for system-to-system auth — CI/CD pipelines and automation tools.
3. Use ServiceAccounts for in-cluster workloads — with projected, short-lived tokens.
4. Prefix OIDC usernames and groups — avoid collisions with system identities.
5. Never share credentials — each user and system should have a unique identity for audit trails.
6. Rotate credentials regularly — certificates should have reasonable expiration, and OIDC tokens are naturally short-lived.