Keyless authentication to Google Cloud Platform using Workload Identity Federation

Google is always working on new ways to improve the security of customer applications running on Google Cloud. Google’s new security improvement is providing keyless authentication for service accounts.

An Application running outside of Google cloud needs to access services in Google cloud outside of the scope of the user, it mostly uses service account keys. Service account keys allow the holder to act as the service account and gain access to any resource that service account has access to.
Unfortunately, there is no way to verify that the application accessing the service account key has the permission to use it. Because of this managing, rotation and storage of service account keys becomes the top priority for any organization running on Google Cloud. Service account keys are powerful credentials and can represent a security risk if they are not managed correctly.

Whats the solution to manage Service accounts keys ?
Ditch the keys 😎

Workload Identity Federation enables applications running outside the Google Cloud to replace long lived Service account keys with temporary credentials called tokens. Using identity federation, you can grant on-premises or multi-cloud workloads access to Google Cloud resources, without using a service account key.

How workload Identity Works ?

1. Your Application authenticate with your identity provider and receive account credentials.
2. The application then can call the Google’s Security Token Service to exchange the account credentials issued by the identity provider for a short-lived Google Cloud Access token.
3. This access token can then used to impersonate the service account and access Google Cloud resources.

Users can use identity federation with Amazon Web Services (AWS), or with any identity provider that supports OpenID Connect (OIDC), such as Microsoft Azure, or SAML 2.0.
The rest of the document talks about Identity Federation with Amazon Web Services

Workload Identity Federation with AWS

Pre-requisites

• Ensure you have the Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin) and Service Account Admin (roles/iam.serviceAccountAdmin) roles on the project. Alternatively, the IAM Owner (roles/owner) basic role also includes permissions to configure identity federation.
• Enable APIs (IAM, Resource Manager, Service Account Credentials, and Security Token Service)
• Create a service account that you want the external Identities to Impersonate

Create a workload Identity Pool

Add a workload identity pool provider

Grant the Workload Identity User role (roles/iam.workloadIdentityUser) to the service account

In the above gcloud command I am binding the service account `wi-aws@demo-sandbox.iam.gserviceaccount.com` workload Identity User role on the member “principalSet://iam.googleapis.com/projects/GOOGLE_PROJECT_NUMBER/locations/global/workloadIdentityPools/demo-test-id/attribute.aws_role/arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/gcp-service-role”.
I am only assigning permissions to a specific gcp-service-role created in AWS. There are different ways to create the identifier for external identities. Kindly refer this document for more information.

Create a credential configuration file that let the application obtain an access token

Now you can use the client-config.json file in the AWS environment to authenticate and access GCP resources without creating a service account key. 😉
For information how we can use the json file to authenticate with GCP, kindly refer the GCP documentation

With this we have come to the end of this blog. I will be publishing more blogs on Federation with Azure and On-Prem. Kindly watch out this space.

Thanks for reading and if you have find it useful, don’t forget to give it a thumbs up. Thank you !!