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.