Skip to content

Kubernetes, roles, and authentication

So far, we've been throwing configurations and changes at Kubernetes and never once has it asked us for a password so you might be wondering how that actually works.

Back when we first created the cluster we ran a command that looked like:

mkdir ~/.kube
k0sctl kubeconfig >~/.kube/config

That setup the connectivity and authentication details we've been using, but it's not clear how that works, or what is in that configuration.

kubeconfig

Kubernetes has a concept called kubeconfig. This is not necessarily a file named kubeconfig though.

By default, kubectl looks for a file named config in the $HOME/.kube directory. You can specify other kubeconfig files by setting the KUBECONFIG environment variable or by setting the --kubeconfig flag.

A basic kubeconfig file looks like this, and as usual, click the for more information.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJ...long base64 string (1)
    server: https://192.168.1.51:6443 (2)
  name: local (3)
contexts: (4)
- context:
    cluster: local
    user: user
  name: Default
current-context: Default
kind: Config
preferences: {}
users:
- name: user (5)
  user:
    client-certificate-data: LS0tLS1CRUdJTiB...long base64 string (6)
    client-key-data: LS0tLS1CRUdJTiBSU0...long base64 string (7)
  1. The is the internal Kubernetes root certificate
  2. This is the hostname and port to connect to
  3. This is a name, used for internal referencing
  4. A context is a combination of cluser, user, and namespace. we'll cover this more later.
  5. The internal name of a user, this is not sent to k8s and k8s does not care about a username defined here.
  6. The x509 client certificate to authenticate to the k8s apiserver.
  7. The k8s root certificate used to sign the client certificate.

Kubernetes use those x509 certificates for mTLS authentication, with the Subject telling Kubernetes who the user is, in this case:

Subject: O=system:masters, CN=kubernetes-admin

Essentially a super-admin. You can find more details about client certificates here

mTLS is great, strong authentication but distributing and managing certificates is a bit painful and kubernetes does not respect CRL or revocation. What do most people do ?

You could use static tokens, or an authenticating proxy but OpenID Connect is the most popular option, and we've already configured that. See the next section for more details.