Authentication

Authentication is about proving the identity. We might see or hear it shortened to authN, pronounced “auth en”.

Credentials are at the heart of authentication, and all requests to the API server include credentials. It’s the responsibility of the authentication layer to verify them. If verification fails, the API server returns an HTTP 401 and denies the request. If it succeeds, the request moves on to authorization.

The authentication layer in Kubernetes is pluggable, and popular modules include client certs, webhooks, and integration with external identity management systems such as Active Directory (AD) and cloud-based Identity Access Management (IAM). In fact, Kubernetes does not have its own built-in identity database. Instead, it forces us to use an external system. This avoids creating yet another identity management silo.

Out-of-the-box, most Kubernetes clusters support client certificates, but we’ll want to integrate with our chosen cloud or corporate identity management system in the real world. Most hosted Kubernetes services automatically integrate with the underlying cloud’s identity management system.

Checking the current authentication setup

Our cluster details and user credentials are stored in a kubeconfig file. Tools like kubectl read this file to determine which cluster to send commands to and which credentials to use. The file is usually stored in the following locations:

• Windows: C:\Users\\<user>\\.kube\config

• Linux/Mac: /home/<user>/.kube/config

Here’s what a kubeconfig file looks like. As we can see, it defines a cluster and a user, combines them into a context, and sets the default context for kubectl commands. The output is snipped to fit the page.