Skip to content

Kubernetes Authentication

Kubernetes Authentication is the process by which the API Server verifies the identity of a client attempting to access the cluster^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]. This is the first step in the security request flow, determining who is making the request, before [[Authorization]] determines what they are allowed to do^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

User Types

In Kubernetes, identities are primarily categorized into two types^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]:

  • Normal Users: These are typically human operators or processes external to the cluster. They are identified via credentials configured within the kubeconfig file's user section and interact with the cluster via kubectl or RESTful requests^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]. Unlike service accounts, normal users are global and not namespaced^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].
  • Service Accounts: These are Kubernetes resources scoped to a specific namespace^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]. They are intended for in-cluster processes, such as Pods, to communicate with the API Server. Kubernetes automatically creates a default ServiceAccount with a token in every namespace for this purpose^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

Authentication Strategies (Authenticators)

Kubernetes supports multiple strategies for verifying client credentials^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]:

  • X.509 Client Certificates: The most common method for normal users^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]. The client presents a certificate signed by the Cluster's CA (Certificate Authority). The API Server validates the certificate to confirm identity^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].
  • Bearer Tokens: A token-based authentication string, often used by Service Accounts^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].
  • OpenID Connect: An identity layer on top of OAuth 2.0^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].
  • Webhook: An HTTP callback mechanism that delegates authentication checks to an external service^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

X.509 Client Certificate Workflow

For normal users, the standard workflow involves creating a private key, generating a Certificate Signing Request (CSR), and having it signed by the cluster's root CA^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

  • Username: The API Server determines the username from the subject's Common Name (CN) field in the certificate^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].
  • Groups: Group membership is derived from the organization (O) field in the certificate subject^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

Once the signed certificate is obtained, it is added to the kubeconfig file using kubectl config set-credentials^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

Relationship to Authorization

Authentication validates identity, but it does not grant permissions^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md]. Even if a user successfully authenticates, they cannot access resources until they pass the Authorization phase (e.g., via [[RBAC]])^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

To verify both authentication and authorization status, the kubectl auth can-i command can be used to check if a specific action is permitted^[400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md].

  • [[Authorization]]
  • [[RBAC]]
  • [[Service Account]]
  • [[Kubernetes API Server]]

Sources

  • 400-devops__06-Kubernetes__k8s-ithelp__Day29__README.md