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.
How Google WIF is Configured in Aembit
Below is the credential provider configuration for Google. You’ll notice there are no hard-coded credentials or API tokens. OIDC is configured to ensure the most secure connectivity possible.
The server workload configuration simply points to bigquery.googleapis.com.
The access policy below specifies the client workload, which is an application running in Kubernetes and identified by the pod name prefix. It allows access to Google BigQuery using Google WIF.
Additionally, the configuration shown below includes the trust provider, which uses a Kubernetes service account to further verify the identity of the client workload when the request is made.
A similar policy can be created where the client workload and trust provider are the same, but the credential provider and/or server workload point to another service or cloud provider.
Here you can see the log showing that Aembit successfully retrieved a short-lived token from GCP identity federation to enable the above access to BigQuery.
Request Code
To keep things simple, we’re making a call to retrieve the records from our employee table. And here’s the result:
{
"kind": "bigquery#tableDataList",
"etag": "KFA1eQ2lJktPJl8JCEs0CA==",
"totalRows": "3",
"rows": [
{
"f": [
{
"v": "Ashur Kanoon"
},
{
"v": "akanoon@aembit.io"
}
]
},
{
"f": [
{
"v": "Mickey Mantle"
},
{
"v": "mm@aembit.io"
}
]
},
{
"f": [
{
"v": "Nolan Ryan"
},
{
"v": "nryan@aembit.io"
}
]
}
]
}
