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 provides a rich set of services(API) e.g. GKE, Translation, Pub/Sub 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.
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 provides mechanisms to generate credentials for consumers. For application consumers it is always recommended to use a SA, 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 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). Each GSA can have one or more JSON Keys called the SA key. 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 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 . The application pods can then mount on these secrets as files
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, 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.
Check the official docs 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_CREDENTIALSand 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 of this series let us see how to apply Workload Identity with a demo.
Top comments (0)