Skip to content

Kubernetes Authentication

Links: 111 KodeCloud Index

Authentication

Kubernetes assumes that users are managed outside of Kubernetes.
  • We CANNOT create or view users in k8s.
  • But we can manage and create service accounts.
  • While Kubernetes defines the concepts of both user accounts and service accounts natively, it doesn’t provide us with a single, built-in method for authenticating those accounts.
  • Different authentication methods are:

X.509 Certificates

  • One of the simplest authentication methods in Kubernetes is to use an X.509 certificate to verify the identity of the user issuing a request.
    • attachments/Pasted image 20230510150004.jpg
  • To use X.509 authentication, you must first create a private key and a Certificate Signing Request, or CSR, for the user account you want to authenticate.
  • You can do this in a Unix-like operating system environment using these commands:
openssl genrsa -out example.key 2048  
openssl req -new -key example.key -out example.csr -subj "/CN=example/O=developers"
Meaning of CN and O.
  • In certificates CN stands for common name and O stands for Organization.
  • CN specifies the name of the user and O specifies the group of the user.
  • The advantage of using O (group) is that we can have multiple users in the group and then assign permission to the group using role binding instead of binding the permission to each user.
  • Then, create a self-signed certificate using the CSR you generated and the certificate authority (CA) associated with your Kubernetes cluster.
openssl x509 -req -in example.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out example.crt -days 30
How to find the location of the CA cert and key?
  • Finding the api-server pod: k get pods -n kube-system attachments/Pasted image 20230510153431.jpg
  • Describing the api-server pod: k describe pod/kube-apiserver-controlplane -n kube-system attachments/Pasted image 20230510153716.jpg

So the cert and the key are present at /etc/kubernetes/pki in the control plane.

ca.crt at /etc/kubernetes/pki is the same certificate but base64 encoded that is present in the certificate-authority-data section of the cluster in the kubeconfig file.

attachments/Pasted image 20230511120344.jpg

??? important] Alternatively we can also use [ kubectl to sign CSR "Alternatively we can also use kubectl to sign CSR**."

  • Next, using kubectl, configure your cluster to use the key and certificate you have created:
kubectl config set-credentials example --client-key=example.key --client-certificate=example.crt
  • Finally, define a context for the certificate:
kubectl config set-context example-context --cluster=<cluster-name> --user=example
Drawbacks of using X.509 certificate authentication
  • While X.509 authentication is straightforward to set up, the major drawback is that it requires you to manage certificates manually.
  • When certificates expire, you’ll need to regenerate them in order to prevent disruptions to authentication.
  • You will also need to remember to revoke certificates for users whose access you want to disable.
  • In short, while this authentication method is simple to configure, it entails a lot of manual effort to manage at scale. It may be appropriate for small-scale clusters where there are only a few users to authenticate, but it will not work well for production environments.

Using kubectl for signing CSR

  • Base64 encoding the csr file: cat example.csr | base64 | tr -d "\n"
    • Or base64 -w 0.
  • Manifest for creating a certificate signing request
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
    name: example
spec:
    groups:
    - developer
    request: <base64 encoded csr certificate>
    signerName: kubernetes.io/kube-apiserver-client
    usages:
    - client auth
  • After creating the singing request using k create -f csr.yml we should see a csr request using k get csr.
  • The csr will be in a Pending state.
  • Approving the CSR of a user as admin: k certificate approve <csr-name>
    • Once approved the csr will be in an Approved state.
  • To get the certificate we use: k get csr <csr-name> -o yaml.
    • The certificate will be under status -> certificate
  • The certificate is base64 encoded and needs to be decoded.
  • Kubernetes Tutorial For Beginners | Kubernetes User Authentication and Authorization - YouTube
    • Quick recap.
  • CSRs signed using kubectl manifests are automatically deleted after sometime.

OpenID Connect Tokens & Identity Provider

  • A second method is to use OpenID Connect (OIDC) tokens.
    • attachments/Pasted image 20230510150100.jpg
  • You can use one of many public OIDC providers, like Google or Okta.
  • The exact implementation steps for OIDC vary depending on which OIDC provider you use; however, the key steps are as follows.
    • First, generate an access_token, id_token and refresh_token from your OIDC provider.
    • Second, edit your kubeconfig file with the OIDC configuration details.
  • OIDC’s major advantage as a Kubernetes authentication method is that, once configured, it will work indefinitely.
  • However, it is relatively complex to set up because it requires generating access tokens using whichever process your OIDC provider supports, then manually writing configuration files that are tailored to those tokens and your provider.
  • OIDC may be more than what is necessary for small-scale Kubernetes clusters, such as those that consist of only a handful of nodes or host just a single workload, but it is worth the effort to configure if you have a large-scale cluster.

Service account authentication token

  • Service account token authentication uses signed bearer tokens to validate authentication requests.
  • To use this method, first create a service account:
kubectl create serviceaccount account-name
  • Creating a token (this will expire) for the service account:
k create token account-name
  • We can then use the bearer token in HTTP headers to issue requests.
  • This method is relatively simple to implement and does not require much ongoing maintenance.
    • However, because you have to create service accounts and associated tokens manually, the initial setup effort is high.
    • In addition, the tokens are short-lived and must be refreshed in order to keep access working.

Static password/token files

  • The simplest, but also least secure, authentication method for Kubernetes is to use static password files.
    • Anyone who gains access to the file can easily modify it to gain unauthorized access to your Kubernetes cluster.
  • To use this method, first generate a password file.
    • Each line of the file should specify the password, username and userID, respectively, for the users you want to authenticate.
    • We can optionally have a fourth column for groups.
    • Separate each value by commas, and create a new line for each new user.
    • In case we are running the kube-apiserver as a service then we need to pass this file as an argument (--basic-auth-file=user-details.csv) in the service definition and then restart the service.
      • attachments/Pasted image 20230523112732.jpg
    • If we are using the kubeadm setup and running the kube-apiserver as a pod then we need to update the kube-apiserver manifest.
      • Location /etc/kubernetes/manifests in the control plane.
      • Kubelet will automatically restart the apiserver.
      • attachments/Pasted image 20230523113226.jpg
  • This method requires very little effort to configure.
  • Instead of password we can use tokens also.
  • Connecting with the apiserver using curl (Password based authentication)
curl -v -k https://master-node-ip:6443/api/v1/pods -u "user1:password123"
  • Connecting with the apiserver using curl (Token based authentication)
    • We use authorization bearer token in this case.
curl -v -k https://master-node-ip:6443/api/v1/pods --header "Authorization: Bearer <token>"

References

Last updated: 2023-05-23