Kubernetes 101 : API server - Authorizations, authentications and the admission controllers -
The API server is a web server that handles RESTful API over the HTTP protocol.
The API server is also the entry point to the cluster. When we use for example the client program "kubectl", we are connecting to the API-server.
While using the "kubectl" tool to get information about the pods for example using the command "kubectl get pods", the "kubectl" request gets converted into and HTTP request and handed over to the HTTP server -API-server-.
A request, for example the above mentioned command "kubectl get pods", goes through a couple of steps before it gets fulfilled.
Authentication:
The API server needs to authenticate the client that is trying to connect to it, it does it through the client's usernames or IDs.
The API server uses authentication plugins for this task : bearer token, ServiceAccount tokens, ...
Authorization:
When the client is authenticated, the API server uses an authorization plugins to check if the client has the proper permissions for the request.
To check if an action is allowed, for example getting information about all the running pods in the cluster, we could use the below command:
Admission controller:
After the authentication and the authorization phase, the admission controllers take over.
These controllers can modify a request to make it fit within the ranges of valid option - default ortions - they can also reject a request.
Remark:
Requests for creating, modifying or deleting resources go through admission controllers.
Admissions controllers could be activated or de-activated using the
"--enable-admissionplugins" and the "--disable-admission-plugins" parameters.
For example:
Comments