Authentication and authorization in Kubernetes

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 Kubernetes API server is made of several modules.

The first component is in charge of authenticating requests.

Kubernetes differentiates between internal and external users.

  1. Kubernetes managed users: user accounts created by the Kubernetes cluster itself and usually used by in-cluster apps (i.e. workload identities).
  2. 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:

Each plugin has strengths and weaknesses and offers a different mechanism to authenticate identities.

The authentication module in the Kubernetes API is pluggable.

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.

Role-based- Access Control in Kubernetes

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.

Authentication between microservices using Kubernetes identities

You can explore how to do so in this article about authentication between microservices using Kubernetes identities.