Accessing Kubernetes API

The API#

Every interaction with Kubernetes goes through its API and needs to be authorized. That communication can be initiated through a user or a service account. All Kubernetes objects currently running inside our cluster are interacting with the API through service accounts. We won’t go deep into those. Instead, we’ll concentrate on the authorization of human users.

Checking out the port#

Typically, the Kubernetes API is served on a secured port. Our k3d cluster is no exception. We can check the port from the kubectl config.

We used jsonpath to output the cluster.server entry located in the cluster with the name k3d-mycluster.

The output is as follows.

We can see that kubectl accesses the Kubernetes API on the port 32867 (this value can be different on your system). Since the access is secured, it requires certificates that are stored as the certificate-authority entry.

As we are working with k3d, the certificates are set up by k3d itself in the /var/lib/rancher/k3s/server/tls directory. While creating the cluster, we will create a volume to map the directory of k3d on our local directory, namely /usercode/certs. We can check the contents of this directory by listing the /usercode/certs directory:

The output is as follows.

...
client-ca.crt
client-ca.key
server-ca.crt
server-ca.key
...

The real-world scenario#

If this was a “real” cluster, we’d need to enable access for other users as well. We could send them the certificate we already have, but that would be very insecure and would lead to a lot of potential problems. Soon, we’ll explore how to enable other users to access the cluster securely. For now, we’ll focus on the exploration of the process Kubernetes uses to authorize requests to its API.

Understanding the process#

Each request to the API goes through three stages.

• Authentication
• Authorization
• Passing the admission control

Authentication#

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. In the authentication process, the username is retrieved from the HTTP request. If the request cannot be authenticated, the operation is aborted with the status code 401.

Authorization#

Once the user is authenticated, the authorization validates whether it is allowed to execute the specified action. The authorization can be performed through ABAC, RBAC, or Webhook modes.

Passing the Admission Control#

Finally, once a request is authorized, it passes through admission controllers. They intercept requests to the API before the objects are persisted and can modify them. They are advanced topics that we won’t cover in this chapter.

Authentication is pretty standard, and there’s not much to say about it. On the other hand, admission controllers are too advanced to be covered just yet.

Try it yourself#

A list of all the commands used in the lesson is given below.

Troubleshooting tips for minikube#

While working with minikube locally, you will need to use the following commands.

The ca.crt certificate was created with the Minikube cluster and, currently, provides the only way we can access the API.