26 lines
15 KiB
JSON
26 lines
15 KiB
JSON
{
|
||
"schema_version": 1,
|
||
"saved_at": "2026-08-07T05:19:24.8862857Z",
|
||
"content_sha256": "d45463a41af112d1ec542b97cdaa3b20e6ccc47f4ef29d95db9d5f722f82439f",
|
||
"result": {
|
||
"title": "How to Set Up GCP Workload Identity Federation for Cross-Cloud Access | how2",
|
||
"url": "https://how2.sh/posts/how-to-set-up-identity-federation-controls-in-cloud-platforms/",
|
||
"snippet": "Configure GCP Workload Identity Federation to let AWS and Azure workloads access Google Cloud APIs without service account keys.",
|
||
"content": "Markdown\n\nLink\n\nAI Prompt\n\nListen\n\nAa\n\nSave\n\nOpen in\n\nChatGPT\n\nClaude\n\nCopilot\n\nGemini\n\nPerplexity\n\nGrok\n\nDeepSeek\n\nTable of Contents\n\nSections\n\nStack Check #\n\nGCP project with IAM admin permissions\n\nAn external workload running on AWS (EC2, ECS, Lambda) or Azure (VMs, AKS, Functions)\n\ngcloud CLI installed and authenticated\n\nCurrently using a GCP service account key file (the thing we are replacing)\n\nAWS CLI or Azure CLI configured on the external workload\n\nWhy Workload Identity Federation Replaces Key Files #\n\nGCP service account key files ( credentials.json ) are the cloud equivalent of passwords checked into source control. They are long-lived (no expiry by default), portable (anyone with the file has access), and impossible to revoke without disrupting every system using the same key.\n\nWorkload Identity Federation lets external workloads (AWS, Azure, on-premises) exchange their native identity token for a short-lived GCP access token. No key file stored anywhere.\n\nThe flow:\n\nAWS EC2 instance gets its IAM role credentials from the instance metadata service\n\nApplication exchanges the AWS STS token for a GCP STS token via Workload Identity Federation\n\nGCP validates the AWS token against the configured trust relationship\n\nApplication receives a short-lived GCP access token (1 hour, auto-refreshed)\n\nCreate a Workload Identity Pool and Provider #\n\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n\n# Create a workload identity pool (one per trust boundary)\ngcloud iam workload-identity-pools create aws-pool \\\n--project = my-gcp-project \\\n--location = global \\\n--display-name = \"AWS Workloads\"\n# Created workload identity pool [aws-pool].\n\n# Create an AWS provider in the pool\ngcloud iam workload-identity-pools providers create-aws aws-provider \\\n--project = my-gcp-project \\\n--location = global \\\n--workload-identity-pool = aws-pool \\\n--account-id = 123456789012\n# Created workload identity pool provider [aws-provider].\n# The account-id is your AWS account number\n\n# Verify the provider\ngcloud iam workload-identity-pools providers describe aws-provider \\\n--project = my-gcp-project \\\n--location = global \\\n--workload-identity-pool = aws-pool \\\n--format = \"value(name)\"\n# projects/111222333/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider\n\nGrant the Federated Identity Access to GCP Resources #\n\nBind the external identity to a GCP service account:\n\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n\n# Create a GCP service account for the workload\ngcloud iam service-accounts create aws-data-pipeline \\\n--project = my-gcp-project \\\n--display-name = \"AWS Data Pipeline\"\n\n# Grant the service account permissions on GCP resources\ngcloud projects add-iam-policy-binding my-gcp-project \\\n--member = \"serviceAccount: [email protected] \" \\\n--role = \"roles/bigquery.dataEditor\"\n\ngcloud projects add-iam-policy-binding my-gcp-project \\\n--member = \"serviceAccount: [email protected] \" \\\n--role = \"roles/storage.objectViewer\"\n\n# Allow the federated AWS identity to impersonate this service account\n# Restrict to a specific AWS IAM role ARN\ngcloud iam service-accounts add-iam-policy-binding \\\n[email protected] \\\n--project = my-gcp-project \\\n--role = \"roles/iam.workloadIdentityUser\" \\\n--member = \"principalSet://iam.googleapis.com/projects/111222333/locations/global/workloadIdentityPools/aws-pool/attribute.aws_role/arn:aws:sts::123456789012:assumed-role/data-pipeline-role\"\n\nGenerate the Credential Configuration File #\n\nThis file tells the GCP client library how to exchange the AWS credential for a GCP token. It contains no secrets – just metadata about the federation setup:\n\n# Generate the credential config file\ngcloud iam workload-identity-pools create-cred-config \\\nprojects/111222333/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider \\\n--service-account = [email protected] \\\n--aws \\\n--output-file = gcp-credentials.json\n\n# View the generated file (no secrets inside)\ncat gcp-credentials.json\n\n10\n11\n12\n13\n\n\"type\" : \"external_account\" ,\n\"audience\" : \"//iam.googleapis.com/projects/111222333/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider\" ,\n\"subject_token_type\" : \"urn:ietf:params:aws:token-type:aws4_request\" ,\n\"service_account_impersonation_url\" : \"https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/ [email protected] :generateAccessToken\" ,\n\"token_url\" : \"https://sts.googleapis.com/v1/token\" ,\n\"credential_source\" : {\n\"environment_id\" : \"aws1\" ,\n\"region_url\" : \"http://169.254.169.254/latest/meta-data/placement/availability-zone\" ,\n\"url\" : \"http://169.254.169.254/latest/meta-data/iam/security-credentials\" ,\n\"regional_cred_verification_url\" : \"https://sts.{region}.amazonaws.com?Action=GetCallerIdentity\u0026Version=2011-06-15\"\n\nUse Federated Credentials in Application Code #\n\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25\n26\n27\n28\n29\n\n# app.py - Access GCP BigQuery from an AWS EC2 instance\n# No service account key file needed\n\nimport os\nfrom google.cloud import bigquery\n\n# Point to the credential config (not a key file)\nos . environ [ \"GOOGLE_APPLICATION_CREDENTIALS\" ] = \"/app/gcp-credentials.json\"\n\n# The client library automatically:\n# 1. Reads AWS credentials from EC2 instance metadata\n# 2. Exchanges them for a GCP token via STS\n# 3. Impersonates the GCP service account\n# 4. Refreshes the token before expiry\n\nclient = bigquery . Client ( project = \"my-gcp-project\" )\n\nquery = \"\"\"\nSELECT date, total_revenue\nFROM `my-gcp-project.analytics.daily_summary`\nWHERE date \u003e= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)\nORDER BY date DESC\n\"\"\"\n\nresults = client . query ( query )\nfor row in results :\nprint ( f \" { row . date } : $ { row . total_revenue : ,.2f } \" )\n# 2026-02-12: $45,230.50\n# 2026-02-11: $41,875.00\n\n10\n11\n12\n13\n14\n15\n16\n\n# Test from the command line on the EC2 instance\nexport GOOGLE_APPLICATION_CREDENTIALS = /app/gcp-credentials.json\n\n# This uses the federated credential automatically\ngcloud auth login --cred-file = /app/gcp-credentials.json\ngcloud auth list\n# ACTIVE ACCOUNT\n# * [email protected]\n\n# Verify it works\nbq query --use_legacy_sql = false 'SELECT 1 as test'\n# +------+\n# | test |\n# +------+\n# | 1 |\n# +------+\n\nSet Up for Azure Workloads #\n\nThe same pattern works for Azure with an OIDC provider instead of AWS:\n\n10\n11\n12\n13\n14\n15\n\n# Create an Azure provider in the pool\ngcloud iam workload-identity-pools providers create-oidc azure-provider \\\n--project = my-gcp-project \\\n--location = global \\\n--workload-identity-pool = aws-pool \\\n--issuer-uri = \"https://sts.windows.net/AZURE_TENANT_ID/\" \\\n--allowed-audiences = \"api://my-gcp-federation\"\n\n# Generate credential config for Azure\ngcloud iam workload-identity-pools create-cred-config \\\nprojects/111222333/locations/global/workloadIdentityPools/aws-pool/providers/azure-provider \\\n--service-account = [email protected] \\\n--azure \\\n--app-id-uri = \"api://my-gcp-federation\" \\\n--output-file = gcp-azure-credentials.json\n\nReal-World Replay #\n\nA fintech company ran data pipelines on AWS (EMR, Lambda) that wrote results to GCP BigQuery and Cloud Storage. They had 14 GCP service account key files distributed across AWS services.\n\nMigration to Workload Identity Federation: 3 days for all 14 workloads. Most time was spent identifying which AWS IAM role each workload used.\n\nDeleted all 14 service account key files. Some had been created 3 years ago and stored in AWS Secrets Manager (which required rotation management) and in some cases directly in EC2 user data (visible in plaintext to anyone with EC2 describe access).\n\nToken exchange latency: 200-400ms on first request (GCP STS call). Subsequent requests use cached tokens until the 1-hour expiry. No measurable impact on pipeline performance.\n\nThe principal binding ( attribute.aws_role/arn:aws:sts::... ) ensures only the specific AWS IAM role can access GCP. When an engineer accidentally attached a different IAM role to a test Lambda, the GCP access was denied with a clear error message referencing the trust policy.\n\nAudit trail improved: GCP Cloud Audit Logs now show the originating AWS role ARN for every API call, making cross-cloud forensics possible.\n\nCheat Sheet Snapshot #\n\nAction\n\nCommand\n\nCreate identity pool\n\ngcloud iam workload-identity-pools create POOL --location=global\n\nCreate AWS provider\n\ngcloud iam workload-identity-pools providers create-aws NAME --account-id=AWS_ACCOUNT\n\nCreate OIDC provider\n\ngcloud iam workload-identity-pools providers create-oidc NAME --issuer-uri=URL\n\nGrant impersonation\n\ngcloud iam service-accounts add-iam-policy-binding SA --role=roles/iam.workloadIdentityUser --member=principalSet://...\n\nGenerate cred config\n\ngcloud iam workload-identity-pools create-cred-config PROVIDER --output-file=creds.json\n\nTest authentication\n\ngcloud auth login --cred-file=creds.json \u0026\u0026 gcloud auth list\n\nList pool providers\n\ngcloud iam workload-identity-pools providers list --workload-identity-pool=POOL --location=global\n\nGotcha Radar #\n\nCredential config file is not a secret, but treat it carefully : The generated JSON contains no credentials, only metadata about how to exchange tokens. However, it reveals your GCP project, pool, and service account names. Do not commit it to public repos.\n\nAWS IMDSv2 required : If your EC2 instances use IMDSv1 (the older metadata service), the credential exchange works but is vulnerable to SSRF attacks that could steal the AWS token. Enforce IMDSv2 ( HttpTokens: required ) on all EC2 instances that use federation.\n\nToken refresh happens automatically but adds latency : The first API call after token expiry takes 200-400ms longer (STS exchange). For latency-sensitive applications, pre-warm the credential by making a dummy API call on startup.\n\nPrincipal binding must be exact : The --member in the IAM binding must exactly match the AWS role ARN format used during token exchange. AWS assumed-role ARNs include the session name ( assumed-role/ROLE_NAME/SESSION ). Use principalSet:// with attribute.aws_role to match the role regardless of session name.\n\nQuotas : Workload Identity Federation has a default quota of 100,000 token exchanges per day per pool. High-throughput workloads (Lambda functions invoked thousands of times) can hit this. Request a quota increase or cache tokens in application code.\n\nWhen NOT to Use This Approach #\n\nAll your workloads run on GCP. Use attached service accounts on GCE/GKE/Cloud Run instead. Workload Identity Federation is specifically for external (non-GCP) workloads. GKE Workload Identity (different feature, similar name) is the native approach for Kubernetes pods on GKE.\n\nYou need human user access to GCP. Workload Identity Federation is for machine-to-machine authentication. For human users, use Google Workspace SSO, Cloud Identity, or SAML federation with your IdP.\n\nYour external workload has no native identity. Bare metal servers without an IdP-issued identity token cannot use federation directly. You need an identity broker or a local OIDC token issuer (like HashiCorp Vault) as an intermediary.\n\nVersion Pulse #\n\nComponent\n\nVersion\n\nNotes\n\nGCP Workload Identity Federation\n\nGA\n\nAWS, Azure, OIDC providers supported\n\ngcloud CLI\n\n450+\n\nFull federation management commands\n\nGoogle Cloud Client Libraries\n\nLatest\n\nAutomatic credential exchange in Python, Go, Java, Node.js\n\nAWS STS\n\nCurrent\n\nToken source for AWS-to-GCP federation\n\nFAQ #\n\nHow is this different from GKE Workload Identity?\nGKE Workload Identity maps Kubernetes service accounts to GCP service accounts for pods running on GKE. Workload Identity Federation maps external identities (AWS IAM roles, Azure managed identities, OIDC tokens) to GCP service accounts for workloads running outside GCP. Similar names, different mechanisms.\n\nWhat happens if the external cloud provider is down?\nIf AWS IAM or the AWS metadata service is unavailable, the workload cannot obtain an AWS token to exchange. The GCP credential refresh fails and API calls return authentication errors. This is the same failure mode as any dependency on the cloud provider’s identity system – your workload already depends on it for AWS API access too.\n\nCan I use Workload Identity Federation with on-premises servers?\nYes, if you have an OIDC-compliant identity provider (like Active Directory Federation Services, Keycloak, or HashiCorp Vault). Configure an OIDC provider in the workload identity pool pointing to your on-premises IdP’s issuer URL. The server obtains an OIDC token from the local IdP and exchanges it for a GCP token.\n\nRelated Guides #\n\nHow to Set Up Mutual TLS\n\nHow to Set Up Security Monitoring with Wazuh\n\nHow to Set Up VPN Split Tunneling Securely\n\nEmbed this command\n\nContinue where you left off?\nResume\n\nWas this helpful?\n\nThanks for the feedback!\n\nAbout the Author\n\nQasim is a Site Reliability Engineer and Cloud Infrastructure Specialist with AWS quad-certification (Solutions Architect, DevOps Engineer, Developer, SysOps), specializing in AI agents and intelligent automation.\n\nWorking with Go, Python, Terraform, and LLM tooling to build systems that don't just run, but reason.",
|
||
"content_type": "text/html",
|
||
"query": "Wie wird Workload Identity Federation in GCP Cloud Storage eingerichtet und mit externen Identitätsanbietern verbunden?",
|
||
"language": "de-DE",
|
||
"round": 2,
|
||
"fetched": true,
|
||
"relevant": true,
|
||
"relevance": 0.9400000000000001,
|
||
"source_quality": "primary",
|
||
"source_quality_score": 0.904,
|
||
"actionable": true,
|
||
"covered_gap_ids": [
|
||
"GAP-001"
|
||
],
|
||
"assessment_reason": "Die Quelle beschreibt die Einrichtung von Workload Identity Federation in GCP mit konkreten Schritten, einschließlich der Erstellung von Workload Identity Pools und Providers, der Zuordnung von externen Identitäten zu GCP-Service Accounts und der Generierung von Credential-Config-Dateien. Sie ist technisch belastbar und bietet umsetzbare Schritte."
|
||
}
|
||
}
|