Aembit today announced support for Google Workload Identity Federation (WIF). While Google WIF issues short-lived security tokens for accessing GCP services, the Aembit Workload IAM Platform  enhances your deployment by eliminating the need for managing secrets or modifying developer code for authentication. Aembit adds an extra layer of security with MFA and conditional access for non-human identities, even when the service itself doesn’t natively support those features.

Why Use WIF and Aembit

Before diving into the configuration details, it’s important to understand why Workload Identity Federation (WIF) with Aembit is beneficial.

Secure Access for Applications 

Applications hosted outside Google Cloud can securely access cloud resources without managing service account keys, reducing the risk of credential leakage. Aembit mints a token and injects it without requiring any code changes, regardless of where the application is hosted or what resource it accesses.

Hybrid and Multi-Cloud Environments

 Organizations operating in hybrid or multi-cloud setups can unify workload identity management across various environments using a single identity source. This simplifies access management and provides centralized visibility. Aembit can be deployed on-premises, between SaaS and cloud providers, and in serverless environments.

Migration to Cloud

During migrations to single or multi-cloud environments, existing applications can seamlessly access cloud resources using their current identities without re-architecting the authentication process. The switch can be flipped in Aembit’s policy without changes to the application or identity provider.

Temporary Access

For workloads requiring temporary or ephemeral access to cloud resources, Workload Identity Federation enables the issuance of short-lived tokens, enhancing security. Aembit’s conditional access policies can further restrict this temporary access by controlling where connections come from and when access is available. One-time access is now more secure with minimal overhead.

Using WIF With Aembit in the Real World

Here’s an example of how you can take advantage of Aembit’s WIF support. If you have a GitLab pipeline that runs code in GitHub to update supplier records in Google BigQuery, you can use a newly minted, short-lived token tied to a specific service account. Since the GitHub code doesn’t contain any authentication information for Google BigQuery, even if the repository is public, there’s no risk of credential leakage. If you need to deploy a disaster recovery (DR) site in another hyperscaler, you would simply update the GitHub code with a call to the new database, add a flag to switch between the two databases, and create a new policy in Aembit. Aembit will detect the new call and inject the short-lived token automatically.

How Aembit GCP WIF Support Works

The diagram below provides an overview of how Aembit’s GCP WIF support works. On the GCP side, WIF is enabled along with workload identity pools. A service account is created to access a Google Cloud resource. When Google WIF is configured, access between the resource and your workload does not directly use the service account. Instead, Aembit first verifies that the workload is authorized to access the resource and requests a short-lived token using WIF’s security token service. In GCP, the token is associated with the service account that has permission to access the resource. Aembit then injects the short-lived token into the workload API call, enabling authenticated communication between the workload and the GCP resource.