How to provide controlling access to Kubernetes API

Whenever any user or k8s service account made an HTTP request to an API server, than that request broadly goes through following stages :

1. Authentication
2. Authorization
3. Admission control

An HTTP request stages inside API Server

API server’s and system certificates

In typical k8s cluster API server runs on port 6443. And whenever any user creates a cluster on its local machine than on $USER/.kube/config a certificate is automatically installed.

API server has its own signed certificate and to authenticate a client it uses $USER/.kube/config file certificate as a system’s default certificate.

Authentication

So this is the first stage for HTTP request in API server environment. This takes complete HTTP request as input although it just needs client certificate and/or headers.

Currently there are many authentication modules like password, JWT tokens, Bootstrap tokens, Plain tokens ?and client certificates.

we can enable multiple modules and if any one passes then request is authenticated.

After authentication API server passes username and it is further used in all stages.

Authorization

This is the second step and checks for user’s access for particular action. This takes requestor username, requested action and object affected by the action as an input.

Suppose user has only access to read pods in projectCaribou namespace. Then his following request will be authorized

An authorized HTTP request

but if we use “verb” :“post” , then request is not authorized.

k8s supports ABAC mode, RBAC mode and webhook mode as different authorization modules.

We can enable multiple modules and if any one passes then request is authorized.

Admission Control

These modules can change or reject the request, they act on those objects that are created/updated/deleted/connected(proxy), but not read.

We can enable multiple modules but if any one fails then request is failed.

Once a request passes all admission controllers, it is validated using the validation routines for the corresponding API object, and then written to the object store (shown as step 4).