Introduction
If you have been using Kubernetes for a while, you probably know that Kubernetes does not offer any built-in mechanism for defining and managing users. This means that Kubernetes does not store any reference to users or groups to which they belong in its object store ETCD. This allows admins to integrate their organization identity service provider, and enables cloud providers to integrate their cloud identity service offering with the likes of Google Cloud Identity and Microsoft AD. This permits working with Kubernetes without having to recreate those users and manage them twice.
In this blog, we will go into the details of how users are created with Google Kubernetes Engine (GKE), and we’ll discuss how Google Cloud IAM and RBAC play together to achieve a better authentication and authorization strategy for your cluster.
Background
Every request made to Kubernetes is an API call that goes through the RESTful interface provided by the Kubernetes API Server (kube-apiserver). This works the same internally when different Kubernetes components, such as the scheduler, kubelets, or kube-proxy, wish to change or retrieve cluster state from ETCD to communicate with each other. Their requests must go through the API server, which will then know how to handle it on their behalf.The kube-apiserver performs three main consecutive tasks for each incoming request before modifying the cluster state. These tasks are: authentication, authorization, and admission control, as shown below in the graph. In the next section, we will explain the notion of identity in Kubernetes, and how the API server tackles authentication and authorization, both from a general perspective and a GKE perspective.
