Authentication verifies the identity of a user, workload, or system before the Kubernetes API evaluates authorization. Human kubectl requests commonly use signed X.509 client certificates stored in kubeconfig files; pods commonly use Service Account tokens. section 3.1
Kubernetes supports several authentication paths and identity types:
- Use X.509 certificate authentication to identify users through a signed client certificate and Kubernetes certificate authority. section 3.1
- Use Service Accounts and associated tokens for machine-to-machine requests from pods. section 3.1
- Configure or encounter bearer tokens, OpenID Connect, and webhooks as additional API-server authentication mechanisms; one successful method is sufficient. section 3.1
- Treat authentication as distinct from RBAC authorization: authentication establishes identity, while roles and bindings restrict permitted API actions. section 3.1 section 9.3.2
User and pod access
A kubectl request presents a client certificate from kubeconfig so the API server can map the requester to a username. A pod instead accesses the API with its mounted Service Account identity and token. Verify available Service Accounts with `kubectl get sa`; the default account appears in the namespace listing. section 3.1
