Skip to content



Concept Description
User Accounts
  • For the API server to authenticate a request, the request issuer needs to possess an identity
  • Kubernetes does not have objects which represent normal user accounts:
    • it assumes that users are managed outside Kubernetes via LDAP, SSO, SAML, etc.
    • user accounts are considered cluster-wide
    • make sure that the usernames are unique across namespaces
Service Accounts Description:
  • Resource that you can use if your application needs to communicate with the API server
  • Managed by the Kubernetes API
  • Bound to specific namespaces
  • If you don't explicitly specify a service account in the pod spec, the default service account for the namespace is used
  • General form: system:serviceaccount:$NAMESPACE:$NAME
Stored as Secret:
  • By default, Kubernetes makes the credentials of the service account available via a Secret that is mounted into the pod
  • They allow in-cluster processes to talk to the Kubernetes API:
    • $ kubectl run -it --rm jumpod --restart=Never --image=alpine -- sh
    • $ ls /var/run/secrets/
  • The token file is a JSON Web Token, can be inspected using the debugger provided by
Using tokens:
  • The token should be included when sending an API request
  • With this token, an attacker can impersonate the service account and use the APIs
    • $ curl -k -v -H "Authorization: Bearer <JWT_TOKEN>" -H "Content-Type: application/json" https://<MASTER-IP>:6443/api/v1/namespaces/default/secrets


Concept Description
  • Most interactions with Kubernetes are done by talking to the kube-apiserver of the control plane
  • Requests pass through 3 steps in the kube-apiserver before the request is served or rejected:
    1. Authentication
    2. Authorization
    3. Admission Control
  • Once requests pass these 3 steps, kube-apiserver communicates with¬†Kubelets over the network
  • Kubelets also have to check authentications and authorizations
Process Every process inside or outside the cluster must authenticate when making requests to the API server, or be treated as an anonymous user:
  1. The client presents its credentials to the API server
  2. The API server uses one of the configured authentication plugins to establish the identity with an identity provider
  3. The identity provider verifies the request information, including username and group membership
  4. If the credentials are in order, the API server moves on to check permissions. Otherwise, it returns an HTTP 401 Unauthorized client error


Authentication strategies are represented by authentication plugins:

Concept Description
Static Tokens
  • The API server requires the client to provide an Authorization HTTP header with value of Bearer $TOKEN
  • Avoid them due to credentials being transmitted over the network in cleartext
Bootstrap Tokens
  • Experimental feature targeting the cluster setup phase and can be used with installers such as kubeadm
  • Avoid them due to their non-ephemeral nature
Basic Authentication
  • Uses the Basic HTTP authentication scheme
  • The API server requires the client to provide an Authorization HTTP header with value of Basic base64(USER:PASSWORD)
  • Avoid them due to credentials being transmitted over the network in cleartext
X509 client certs
  • Every user has their own X.509 client certificate
    • the API server then validates the client certificate via a configured certificate authority (CA)
    • if the client certificate is verified successfully, the common name of the subject is used as the username for the request, and any organizations defined for the subject are used as groups
    • admins need to manage access to the CA as well as issue the client certificates, and reissue them
  • Decent authentication strategy, but you'd have to address renewing and redistributing client certs on a regular basis
Service Account Tokens
  • Should not be used for end-users trying to interact with Kubernetes clusters
  • They are the preferred authentication strategy for applications & workloads running on Kubernetes
OpenID Connect (OIDC) Tokens
  • Identity layer on top of the OAuth 2.0
  • Use OIDC to provide the API server with an id-token in the form of a JSON Web Token after using your provider's login page
  • Best authentication strategy for end users as OIDC integrates with your identity provider (e.g. AD, AWS IAM, etc.)