Google unveils Workload Identity to spur secure Cloud service usage in GKE apps

Google unveils Workload Identity to spur secure Cloud service usage in GKE apps

Google has introduced the concept of the Workload Identity as a means of authentication to make using Google Cloud services for Google Kubernetes Engine (GKE) apps that little bit more secure. 

It basically boils down to configuring Kubernetes service accounts (KSA) in a way that they can act as Google service accounts (GSA). A so-called Identity Namespace, which is associated with a project, defines the relationship between KSA and GSA for that. 

Once this has been set up, pods with a Google Service Account Identity can be started, meaning that workloads are able to authenticate as said service account when accessing Google Cloud APIs. Workloads on existing clusters can be migrated to make use of the new concept – a step by step guide can be found in the documentation.

Credentials issued to the Workload Identity are shorter lived then service account keys, and they are managed by Google, which is meant to lower the risk of accidental disclosure. The approach also enforces the principle of least privilege by only giving enough permissions for workloads to do what they should.

Those aspects are important to Google, since they should tackle the weaknesses of alternative methods to access Cloud APIs from GKE. Those mainly entailed using the Compute Engine default service account, and exporting service account keys and storing them as Kubernetes secrets.

The former runs the danger of over-provisioning permissions, while the latter is linked to management overhead in the form of key inventory and rotation. After all, service account keys expire after ten years, which might turn into a bit of a long-term problem if you don’t rotate and a key becomes compromised for example.

To use Workload Identity, which is still in beta at this point, customers need to have the GKE API enabled, the Cloud SDK installed, and the latest version of gcloud. Other than that defaults for project IDs, compute zones (if working with zonal clusters), and compute region (if regional clusters are what you’re dealing with) have to be set and your cluster has to run on GKE 1.12 or higher.