Introducing Workload Identity: Better authentication for your GKE applications

An application has needs. Maybe it needs to connect to a data warehouse, or connect to a machine learning training set. No matter what your application needs to do, there’s a good chance it needs to connect to other services to get it done.

If that app runs on Kubernetes, this kind of authentication has traditionally been a challenge, requiring workarounds and suboptimal solutions. Which is why today we’re excited to announce Workload Identity, the new–and now recommended–way for GKE applications to authenticate to and consume other Google Cloud services. Currently in beta, Workload Identity works by creating a relationship between Kubernetes service accounts and Cloud IAM service accounts, so you can use Kubernetes-native concepts to define which workloads run as which identities, and permit your workloads to automatically access other Google Cloud services–all without having to manage Kubernetes secrets or IAM service account keys!

Authentication in GKE: an overview

To better understand Workload Identity, let’s look at your various authentication options for apps running on GKE. Before Workload Identity, there were two primary methods for authenticating GKE workloads to Google Cloud APIs: Storing service account keys as Kubernetes secrets, or using the node’s IAM service account. Both of these approaches have drawbacks in terms of ease of management and security.

Service account keys as secrets
A Cloud IAM service account is an identity that an application can use to make requests to Google APIs. As an application developer, you could generate individual IAM service accounts for each application, and then download and store the keys as a Kubernetes secret that you manually rotate. Not only is this process burdensome, but service account keys only expire every 10 years (or until you manually rotate them). In the case of a breach or compromise, an unaccounted-for key could mean prolonged access for an attacker. This potential blind spot, plus the management overhead of key inventory and rotation, makes using service account keys as secrets a less than ideal method for authenticating GKE workloads.

Node’s IAM service account
Since every GKE node is a Compute Engine instance, applications running on GKE inherit the properties of the underlying Compute Engine VM, including its IAM service account. You could give your pod access to this account, and use this to authenticate to other Google Cloud services. However, container architectures are dense by design–this means that when you’re running Kubernetes, you might want one pod to have privileged access to a service, but every other pod on the node should not. The principle of least privilege makes this method of authenticating GKE workloads less than ideal.

The new way: Workload Identity
That’s why we introduced Workload Identity, a new way to help reduce the potential “blast radius” of a breach or compromise and management overhead, while helping you enforce the principle of least privilege across your environment. It does so by automating best practices for workload authentication, removing the need for workarounds and making it easy to follow recommended security best practices.

• By enforcing the principle of least privilege, your workloads only have the minimum permissions needed to perform their function. Because you don’t grant broad permissions (like when using the node service account), you reduce the scope of a potential compromise.
• Since Google manages the namespace service account credentials for you, the risk of accidental disclosure of credentials through human error is much lower. This also saves you the burden of manually rotating these credentials.
• Credentials actually issued to the Workload Identity are only valid for a short time, unlike the 10-year lived service account keys, reducing the blast radius in the event of a compromise.

Workload Identity is project wide, so you can use it to grant permissions to new or existing clusters in your projects that share Kubernetes namespaces and Kubernetes service account names. For example, in the add-iam-policy-binding call below, any pod running under the Kubernetes namespace K8S_NAMESPACE and the Kubernetes service account KSA_NAME have permission to use the [GSA_NAME]@[PROJECT_NAME].iam.gserviceaccount.com IAM service account to access Google Cloud services.

Getting started with Workload Identity

After enabling Workload Identity on your cluster, configuring a Kubernetes service account to access Google Cloud services through Workload Identity is a simple, two step process.

When you enable Workload Identity on your cluster, your project receives an “Identity Namespace.” This is a new IAM primitive, used only for Workload Identity at this time. Workload Identity takes care of the intricacies of Identity Namespaces, though, so you don’t have to become an expert on it. (Although, if you’re interested in how Identity Namespaces works, check out our recent talk at Next ’19.)

Here’s how to use Workload Identity: 1) grant the Kubernetes service account permission to use the targeted IAM service account. Here’s a sample command: