Authentication and authorization in Kubernetes
Articles in this series
TL;DR: In this series, you will learn how users and apps are authenticated and authorized in a Kubernetes cluster.
When you execute the kubectl apply, the request is submitted to the cluster.
The API server is the first component in the control plane to receive that request.
The API server parses the requests and stores the object in etcd.
At least, this is the big picture.
Things turn out to be a bit more complicated than that, though.
The API is organized in a collection of components invoked one after the other.
The first component is in charge of authenticating requests.
Kubernetes differentiates between internal and external users.
- Kubernetes managed users: user accounts created by the Kubernetes cluster itself and usually used by in-cluster apps (i.e. workload identities).
- Non-Kubernetes managed users: users that are external to the Kubernetes cluster, such as users authenticated through external identity providers like Keystone, Google account, and LDAP.
If you wish to explore how the authentication module works and how to assign identities to users and workloads, you can continue reading user and workload identities in Kubernetes
The authentication module consists of several authentication plugins that are evaluated in sequence:
- Static Token file.
- X.509 certificates.
- Open ID Connect.
- Authentication proxy.
- Webhook.
Each plugin has strengths and weaknesses and offers a different mechanism to authenticate identities.
If you wish to understand how this works and perhaps build your own, you can read implementing a custom Kubernetes authentication method.
Once one plugin succeeds, the request is passed to the authorization module.
If you are authenticated, the authentication component retrieves your details and packages them into a UserInfo object that the authorization service can consume.
Regarding authorization, Kubernetes implements the Role-based Access Control (RBAC) model for protecting resources in the cluster.
Users are granted access to API endpoints and read, update and create resources.
To manage access to the API, Kubernetes groups permissions into Roles and ClusterRoles.
The link between those identities (users or workload) and the permissions (Role and ClusterRoles) is defined using bindings.
If you want to explore how to grant permissions to resources in a Kubernetes cluster, you can read limiting access to Kubernetes resources with RBAC.
Authentication and authorization aren't just for (human) users, though.
You can combine them to build your microservice to microservice authentication mechanism in the cluster.
You can explore how to do so in this article about authentication between microservices using Kubernetes identities.