AuthN & AuthZ

Authentication (AuthN) and Authorization (AuthZ) are two distinct security processes in Kubernetes. Authentication answers “Who are you?” while Authorization answers “What are you allowed to do?” Think of it like entering a building: authentication is showing your ID at the front desk, and authorization is which floors your keycard can access.

Authentication vs Authorization

Authentication (AuthN) verifies identity:

• Confirms that a user or application is who they claim to be
• Happens first in the request flow
• Uses certificates, tokens, or credentials

Authorization (AuthZ) controls access:

• Determines what actions the authenticated entity can perform
• Happens after authentication succeeds
• Uses RBAC, ABAC, or other authorization modes

Kubernetes Authentication Flow

When a request arrives at the Kubernetes API server:

1. Authentication - The API server tries to identify the requester using configured authentication methods
2. Authorization - Once identified, the API server checks if the requester has permission for the requested action
3. Admission Control - Validating and mutating webhooks can further modify or reject requests
4. Request Processing - If all checks pass, the request is processed

Authentication Methods

Kubernetes supports multiple authentication methods, tried in order:

1. X.509 Client Certificates

Users authenticate using client certificates. The API server validates the certificate against a Certificate Authority (CA).

2. Static Token File

A file containing bearer tokens. Each token is associated with a username and optional groups.

3. Bootstrap Tokens

Temporary tokens used during cluster bootstrap, especially with kubeadm.

4. ServiceAccount Tokens

Automatically created tokens for ServiceAccounts, mounted into pods.

5. OpenID Connect (OIDC)

Integration with external identity providers like AWS IAM, Azure AD, or Google Cloud Identity.

6. Webhook Token Authentication

Delegates token validation to an external service.

User vs ServiceAccount

Kubernetes distinguishes between two types of identities:

• Users - Human operators or external systems accessing the cluster
• ServiceAccounts - Identities for pods and applications running inside the cluster

ServiceAccounts are namespace-scoped resources, while users are not managed by Kubernetes (they’re authenticated externally).

Authorization Modes

After authentication, Kubernetes uses authorization modes to determine permissions:

• RBAC (Role-Based Access Control) - Most common, uses Roles and RoleBindings
• ABAC (Attribute-Based Access Control) - Policy-based, less commonly used
• Node - Authorizes kubelet requests
• Webhook - Delegates authorization decisions to external services

Most clusters use RBAC as the primary authorization mode.

Practical Example

Here’s how authentication and authorization work together:

# 1. ServiceAccount (authentication identity)
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production

---
# 2. Role (authorization permissions)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]

---
# 3. RoleBinding (connects identity to permissions)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: app-role
  apiGroup: rbac.authorization.k8s.io

When a pod uses this ServiceAccount:

1. Authentication: Pod authenticates as system:serviceaccount:production:my-app
2. Authorization: RBAC checks if this identity has permission for the requested action
3. Result: Pod can get/list ConfigMaps in the production namespace

Best Practices

1. Use ServiceAccounts for applications - Never use user credentials in pods
2. Separate ServiceAccounts per application - Isolate permissions by workload
3. Rotate tokens regularly - Especially for long-running applications
4. Use OIDC for human users - Integrate with your organization’s identity provider
5. Audit authentication failures - Monitor failed authentication attempts
6. Limit token lifetime - Use short-lived tokens when possible

Common Patterns

• Read-only ServiceAccounts - For monitoring and logging applications
• Namespace-scoped identities - Limit ServiceAccounts to specific namespaces
• External identity integration - Use OIDC to connect with cloud provider IAM
• Token rotation - Implement automated token rotation for ServiceAccounts

Troubleshooting

Check authentication status:

# View current authentication context
kubectl config current-context
kubectl config view

# Test authentication
kubectl auth can-i get pods --all-namespaces

Debug ServiceAccount authentication:

# Check ServiceAccount exists
kubectl get serviceaccount my-app -n production

# View mounted token
kubectl exec -it <pod-name> -n production -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Test ServiceAccount permissions
kubectl auth can-i --list \
  --as=system:serviceaccount:production:my-app \
  --namespace=production

Topics

• ServiceAccounts - Deep dive into ServiceAccounts and pod identity
• OIDC - OpenID Connect integration with external identity providers

See Also

• RBAC - Role-Based Access Control for authorization
• Secrets Management - Managing authentication tokens and credentials
• Admission Control - Additional request validation