Kubernetes / Security

A Practical Approach to Understanding Kubernetes Authentication

2 Aug 2019 3:00am, by

This article is a part of the Kubernetes security series that started last week. The previous article covered the overview and background of Kubernetes access control. In this part, we will understand the concepts of authentication through the hands-on approach.

In a production environment, Kubernetes administrators use namespaces to isolate resources and deployments. Namespaces act as a logical boundary to enforce basic access control.

Let’s say we have Bob, new admin that joined the DevOps team to manage the Kubernetes deployments for the engineering group. We now have to provide him with just enough access to manage the engineering namespace. Assuming you are the cluster administrator with permissions to manage global resources and objects, you would onboard Bob and help him with the credentials needed to access Kubernetes cluster.

This scenario is based on Minikube but it should work with any other configuration where you are the cluster administrator.

Create a directory called cred and run the below commands to generate a private key for Bob.

We also need a Certificate Signing Request which can be generated from the key.

Move the key to the parent folder and encode that in Base64.

We need to embed the generated base64-encoded string in a YAML file and submit that to Kubernetes as a Certificate Signing Request. This step will essentially associate Bob’s private key with Kubernetes cluster.

Verify the CSR with the below kubectl command:

Notice that the request is still pending. The cluster admin has to approve it before it becomes active.

Now that the certificated has been approved and issued, we need to get the signed certificate from the cluster. This is the most critical step in onboarding Bob.

The file, bob.crt is the client certificate that’s used to authenticate Bob. We now have the combination of the private key (bob.key) and the approved certificate (bob.crt) from Kubernetes. As long as Bob has these two assets, he can get authenticated with the cluster.

It’s time to add Bob as a user to Kubernetes.

Open ~/.kube/config file to verify that the credentials are set.

Let’s also create a new namespace called engineering for which Bob is the administrator.

The kubectl CLI has a very useful switch in the form of auth which can verify the permissions for a specific user. Let’s check if the current user who is the admin has access to the engineering namespace. Given that you are the cluster admin, it’s not surprising to see the output.

We can also check if Bob has got access to the engineering namespace.

It’s obvious that Bob doesn’t have access to the namespace. That’s because we have created the credentials but not explicitly authorized Bob for any specific action on any object.

In the next part of this tutorial series, I will walk you through the steps involved in authorizing Bob. It would also give us an opportunity to learn about roles and role bindings. Stay tuned!

Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2)” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar at http://mi2.live.

Feature image by mohamed Hassan from Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.