Auth
Kubernetes has two types of authentication and authorization by default.
-
mTLS - This authentication type happens only between the core components of the Kubernetes cluster. The cluster contains a cluster wide CA which is created during the cluster installation. This follows the same process as browser and web server. The certificates and it's content is verified and validated using public keys.
-
Service Accounts - This authentication type is for non-core components that are running in the cluster. Here the JWT tokens are issued once and can be used by the component to interact with the API server. These tokens are then sent in the Bearer header from the application using it. The API server only validates if the bearer token is really valid.
This is similar to what happens in OAuth process. The server receives the token in the client request. The server then sends the token to the Auth provider to check if this is valid.
Service Accounts are for servicesIt's important to understand that service accounts are accounts for services running in the cluster. They're just machine accounts.
Since recent versions, the JWT tokens are short lived. The tokens provided have a default lifetime of just one hour. The kubelet on the node hosting the pod is responsible for requesting new tokens and update it in the pod.
If an application wants to watch for changes of a specific resource via API server, it must first request for a service account which is then directly mounted into the requested pod.
The application inside the pod then already knows where to find it's token at the standard location. Then use it for all the Kubernetes API server calls.
Authorization
Both mTLS and service accounts have their subjects in the certificates and JWT tokens respectively. The authorization module then uses this subject name to get it's roles to perform RBAC.
This information about subject to roles is also stored in etcd of the cluster.