Authentication and authorization are important components in Kubernetes. Authentication verifies users and checks that the user is who they claim to be. Authorization, on the other hand, checks what permission levels users have. Kubernetes supports different authentication and authorization modules.

The following is an illustration that shows how the Kubernetes API server processes access control when it receives a request:

When the request goes to the API server, first it establishes a TLS connection by validating the clients' certificate with the Certificate Authority (CA) in the API server. The CA in the API server is usually at /etc/kubernetes/, and the clients' certificate is usually at $HOME/.kube/config. After the handshake, it moves into the authentication stage. In Kubernetes, authentication modules are chain-based. More than one authentication module can be used here. When receiving the request, Kubernetes will try all the authenticators one by one until it succeeds. If the request fails on all authentication modules, it will be rejected with an HTTP 401 Unauthorized error. If not, one of the authenticators verifies the user's identity and the requests are authenticated. At this point, Kubernetes authorization modules come into play.

Authorization modules verify whether or not the user has sufficient permissions to perform the action that they have requested to perform. Authorization modules are also chain-based. The authorization request needs to pass through every module until it succeeds. If the request fails for all modules, the requester will get a HTTP 403 Forbidden response.

Admission control is a set of configurable plugins in an API server that determine whether a request is admitted or denied. At this stage, if the request doesn't pass through one of the plugins, then it is denied immediately.