What is Workload Identity ?
Tags: googlecloud, cloud, kubernetes
Published: 2023-03-13 04:09:15

Awesomeness of using Cloud and its ecosystem is that we don't need to reinvent the wheel, in other words no need to build/deploy services e.g.  database, message queue,AI/ML etc. For any service need the APIs are just a click away.

## Glossary

| Abbreviation | Expansion
| :----:    |:----------:
| API | Application Programming Interface
| ACL | Access Control List|
| GCS | Google Cloud Storage
| GKE | Google Kubernetes Engine
| GSA | Google Service Account
| IAM | Identity and Access Management
| KSA | Kubernetes Service Account
| RBAC| Role Based Access Control
| SA  | Service Account
| VPC | Virtual Private Cloud

[Google Cloud](https://cloud.google.com) provides a rich set of services(API) e.g. [GKE](https://cloud.google.com/kubernetes-engine/), [Translation](https://cloud.google.com/translate), [Pub/Sub](https://cloud.google.com/pubsub/docs/overview) etc., which can cater most of the distributed application needs with less or no effort.

GKE is one of the most commonly used Google Cloud Service that allows you to deploy Cloud Native services swiftly. In many occasions those applications deployed to GKE tend to leverage the services offered by Google Cloud e.g our application need to call Google Cloud Translation service, publish a message to Pub/Sub topic or upload/download files from [GCS](https://cloud.google.com/storage/).

By virtue of GKE running on a Google Cloud infrastructure, the Kubernetes pods on GKE can't access any Google Cloud service at its wish and will. 

Every API consumer in this case a GKE application needs to be authenticated and authorised to call a Google Cloud API. Google [IAM](https://cloud.google.com/iam/docs/overview) provides mechanisms to generate **credentials** for consumers. For application consumers it is always recommended to use a [SA](https://cloud.google.com/iam/docs/service-account-overview), as Service Accounts are capable of being used as :
- An **principals**  -  Access to Google API can be granted directly to  a principal 
- A **resource**  - Other principals e.g User, Group etc., can be added to a Service Account with specific role scopes.

Check out [Service Account Permissions](https://cloud.google.com/iam/docs/service-account-overview#service-account-permissions) for more details.

## Google Service Account Keys

Great! We understood that every consumer needs a **Google IAM credentials** to call Google Cloud Service API. 

### How do API consumers get this API Credential?

There few ways to do that, for this blog series we will use [Google IAM Service Account(GSA)](https://cloud.google.com/iam/docs/service-account-overview). Each GSA can have one or more JSON Keys called the [SA key](https://cloud.google.com/iam/docs/keys-create-delete). The SA key file has critical information like _private_key_id_, _private_key_, _client_email_, _client_id_ etc., that will be used to identify the SA with with Google Cloud IAM and make necessary service calls.

> IMPORTANT:
>  
> - The JSON key needs to be stored securely
> - The [Google IAM policies](https://cloud.google.com/iam/docs/reference/rest/v1/Policy) determines what authorisations are available for a associated GSA.

### Using GSA JSON Key

All Google API client libraries by default looks for an environment variable `GOOGLE_APPLICATION_CREDENTIALS`, uses it perform required authentication and authorisation. So as developer once we have access to the SA JSON key we set the path of the file as the value of `GOOGLE_APPLICATION_CREDENTIALS` environment variable.

On GKE these credentials are usually stored as [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) . The application pods can then mount on these [secrets as files](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 
 and set the environment variable `GOOGLE_APPLICATION_CREDENTIALS` with the mounted file path.

Though this way of using **static key** file is quick and fast it lacks security and manageability:

- The keys do not have an expiry and has to be manually rotated.
-  Key rotation and compromise has cascading effect i.e if the keys are compromised, it needs to regenerated and shared with all consumers.
- On cloud its recommended to follow [Principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege), which means a GSA be given very few permissions. So if your applications accesses multiple services then it might be required to generate multiple keys one for each service and it becomes harder to rotate all those static keys.

### Is there a **keyless** way to call the APIs?

All that **static key** file does is to identify the caller using the details from the JSON key file with Google Cloud platform. Once its identity is proven a i.e. knowing the associated GSA; a **short living access token** is generated and shared with the consumer. The consumer can then use that token for making all authorised API calls.

So if the application pods i.e. **workload** can identify itself by some mechanism, then we might not need **static key**. Thats exactly what **Workload Identity** is used for.

> **Workload Identity** allows a Kubernetes service account in your GKE cluster to act as an Google IAM Service account. Pods that use the configured KSA automatically authenticate as the IAM service account when accessing Google Cloud APIs.

When GKE is enabled with Workload Identity, the fixed workload identity pool helps Google Cloud IAM to understand the KSA and GSA associated with it i.e. KSA impersonates itself as GSA. With this impersonation the application running with that KSA can call the Google services as the GSA. 


![Workload Identity](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g9n8mitvsidt16o7h4hs.png)

Check the official [docs](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity#how_works) for more details on how Workload Identity works under the hoods.

So with _Workload Identity_ we can work through the drawbacks of **static key** file usage and in addition:

- Provide fine grained access control to each application with KSA and GSA combination.
- The Workload Identity uses **Short Lived Tokens** than _Long Living Static Keys_ thereby adding more security.
- The application workloads no longer need to configure the `GOOGLE_APPLICATION_CREDENTIALS` and assume right keys are available for it.
- For Ops the ACL/RBAC can be centrally managed from Google Cloud Web Console via the Google Cloud IAM

## Summary

- We need Google IAM Credentials to call any Google API
- How to create Google Service Account Key(JSON) i.e. static key
- How to use Google Service Account Key to call Google API
- Use Google IAM Roles/Permissions is used to restrict what APIs a Google Service Account  can call
- How to Google Service Account keys are used by GKE application Pods
- Finally What is a Workload Identity and how it helps in keyless API invocations

In [next part](https://dev.to/kameshsampath/applying-workload-identity-with-a-demo-1bf9) of this series let us see how to apply Workload Identity with a demo.