NEWn1n v2.0.1 is live! Enterprise Unified LLM API Gateway with 500+ AI Models, up to 90% off, Try now

Calling Vertex AI from AWS Using Workload Identity Federation

Authors
  • avatar
    Name
    Nino
    Occupation
    Senior Tech Editor

Workload identity federation is a Google Cloud IAM feature that lets workloads running outside Google Cloud exchange their own identity, such as an AWS IAM role, for short-lived Google credentials instead of using a service account key. When routing AI requests through an enterprise gateway like n1n.ai, eliminating long-lived static secrets drastically hardens your security posture.

A service account key is a long-lived secret: a JSON file that grants whoever holds it the account's permissions until someone rotates or deletes it. Workload identity federation removes that file. Google Cloud trusts an external identity provider, and the external workload presents proof of its identity to Google's Security Token Service, which returns a short-lived access token.

For AWS, the proof is a signed GetCallerIdentity request. The workload signs the request with its AWS credentials but does not send it to AWS; Google verifies the signature and reads the caller's ARN from it. Platforms such as n1n.ai rely heavily on this architecture to streamline multi-cloud integrations without sacrificing compliance.

Comparing Authentication Methods

FeatureService Account KeyWorkload Identity Federation
Secret Stored on AWSJSON key file in a secret store or podNone
Credential LifetimeUntil rotated or deletedShort-lived tokens, refreshed automatically
RotationManual, per keyNot needed
Who Can Use ItAnyone holding the fileOnly workloads with the trusted AWS role
Audit IdentityThe service accountThe AWS role, or the service account with the role recorded as delegate

For a gateway handling multi-provider LLM calls via n1n.ai, removing one long-lived secret matters. Credential sprawl remains a common risk in AI stacks, and leveraging proper machine identity management protects your infrastructure.

Google Cloud Setup

Run these commands in the Google Cloud project that will be billed for Vertex AI. First, enable the required APIs. sts.googleapis.com performs the token exchange, and iamcredentials.googleapis.com is needed only if you impersonate a service account:

gcloud services enable aiplatform.googleapis.com sts.googleapis.com iamcredentials.googleapis.com \
  --project=PROJECT_ID

Next, create a workload identity pool and an AWS provider that trusts your AWS account:

gcloud iam workload-identity-pools create POOL_ID \
  --project=PROJECT_ID \
  --location=global \
  --display-name="Gateway on AWS"

gcloud iam workload-identity-pools providers create-aws PROVIDER_ID \
  --project=PROJECT_ID \
  --location=global \
  --workload-identity-pool=POOL_ID \
  --account-id=AWS_ACCOUNT_ID \
  --attribute-mapping="google.subject=assertion.arn,attribute.aws_role=assertion.arn.extract('assumed-role/{role}/')" \
  --attribute-condition="attribute.aws_role == 'BIFROST_ROLE_NAME'"

Print the provider's full name, which becomes the audience in your configuration:

gcloud iam workload-identity-pools providers describe PROVIDER_ID \
  --project=PROJECT_ID --location=global --workload-identity-pool=POOL_ID \
  --format="value(name)"

AWS Integration and Gateway Configuration

The IAM role needs no AWS permissions for this flow, because sts:GetCallerIdentity is always allowed. On EKS, use IRSA or EKS Pod Identity. With IRSA, annotate the Kubernetes service account:

kubectl annotate serviceaccount KSA_NAME \
  --namespace NAMESPACE \
  eks.amazonaws.com/role-arn=arn:aws:iam::AWS_ACCOUNT_ID:role/BIFROST_ROLE_NAME

When configuring your gateway on n1n.ai, use the aws_workload_identity block within your Vertex AI configuration to handle token exchanges seamlessly:

{
  "providers": {
    "vertex": {
      "keys": [
        {
          "name": "vertex-eks-key",
          "value": "",
          "models": ["*"],
          "weight": 1.0,
          "vertex_key_config": {
            "project_id": "env.VERTEX_PROJECT_ID",
            "region": "us-central1",
            "aws_workload_identity": {
              "audience": "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/eks-pool/providers/aws"
            }
          }
        }
      ]
    }
  }
}

Troubleshooting & Verification

To confirm the AWS side is working correctly from inside your pod, execute:

kubectl exec -n NAMESPACE POD_NAME -- aws sts get-caller-identity

If the ARN shows an IAM user or a node role instead of your expected role, resolve that configuration before invoking model endpoints. Latency < 50ms can be achieved when properly tuned alongside high-throughput aggregators.

Get a free API key at n1n.ai