26 lines
8.2 KiB
JSON
26 lines
8.2 KiB
JSON
{
|
||
"schema_version": 1,
|
||
"saved_at": "2026-08-07T05:19:45.741363Z",
|
||
"content_sha256": "62f36dcae1f14a8a971f40a2f6615024057144e9bf317b3d5d71f8ecfb9b286b",
|
||
"result": {
|
||
"title": "Enable keyless access to GCP with workload Identity Federation | Google Cloud Blog",
|
||
"url": "https://cloud.google.com/blog/products/identity-security/enable-keyless-access-to-gcp-with-workload-identity-federation?hl=en",
|
||
"snippet": "What is workload Identity federation and how do I set it up? Workload identity federation is a new keyless application authentication mechanism that allows your workloads running on-premises, in AWS, or in Azure to federate with an external Identity provider (IdP) and call Google Cloud resources without using a service account key.",
|
||
"content": "Security \u0026 Identity\n\nKeyless API authentication—Better cloud security through workload identity federation, no service account keys necessary\n\nApril 9, 2021\n\nVignesh Rajamani\n\nProduct Manager\n\nOrganizations often have applications that run on multiple platforms, on-premises or cloud. For such applications that call Google Cloud Platform (GCP) APIs, a common challenge admins face is securing long-lived service account keys used to authenticate to GCP. Examples of such applications might include:\n\nAnalytics workloads running on AWS or Azure that access sensitive datasets stored in Google Cloud Storage\n\nCI/CD pipelines that use external tools such as Terraform to provision projects and VMs on GCP\n\nMicroservice-based apps running on GKE that connect to one or more GCP services.\n\nSince these applications rely on service account keys to access GCP APIs, you need to create and manage these credentials and have safeguards in place to ensure that long-lived service keys are well protected, securely distributed, and frequently rotated. If these credentials are compromised, a bad actor can use them to access your resources and data, and put your business at risk. Managing service account keys can become even more challenging as your organization’s cloud consumption and deployment of multi-cloud applications grows, putting you in the unenviable position of having to self-manage thousands of service account credentials or invest in third-party solutions to safeguard these service account keys.\n\nThe best way to alleviate the challenges around service account keys is not to use them at all - and with workload identity federation, a new feature on Google Cloud, you can do just that.\n\nWhat is workload Identity federation and how do I set it up?\n\nWorkload identity federation is a new keyless application authentication mechanism that allows your workloads running on-premises, in AWS, or in Azure to federate with an external Identity provider (IdP) and call Google Cloud resources without using a service account key. Your workloads instead call our security token service (STS) endpoint to exchange the authentication token they obtained from the IdP for a short-lived GCP access token. They then use this access token to impersonate a service account and inherit the permissions of the service account to access GCP resources.\n\nHere are the steps to set up workload identity Federation:\n\n1 .Create a workload identity pool resource object in your GCP project. The workload identity Pool is a new component built to facilitate this keyless federation mechanism. The pool acts as a container for your collection of external identities.\n\n2. Connect one or more of your IdPs to the workload identity Pool. The IdP can be an AWS or Azure account(s) or provider(s) that support OIDC protocol (SAML is coming soon).\n\n3. Grant the pool access to resources by defining two IAM policies:\n\nA policy granting a service account access to desired resources. You can create a new service account or re-use an existing service account.\n\nA policy that allows identities from the pool to impersonate the service account. Detailed information on creating these policies are available in our documentation .\n\n4. Authenticate your workloads to the STS endpoint, impersonate the service account, and have them call the desired GCP APIs.\n\nMore detailed information on how to set up workload identity federation and configure policies can be found here .\n\nIntegration with authentication client libraries\n\nWe’ve provided extensive client library support in many languages to help your application developers simplify and secure the authentication process with minimal coding. We highly-recommend you use them.\n\nHere’s an example of how developers can can start using workload identity pools with the Google Cloud Client libraries in two steps:\n\nGenerate the credentials configuration file for your workload identity pool provider:\n\nLoading...\n\ngcloud iam workload-identity-pools create-cred-config \\\n# Workload identity pool provider resource name.\nprojects/project-number/locations/global/workloadIdentityPools/pool-id/providers/aws-pid \\\n# Service account to impersonate.\n--service-account gsa-name@project-id.iam.gserviceaccount.com \\\n# Generate configuration file for AWS VM.\n--aws \\\n# Output file location.\n--output-file credentials.json\n\nSet the GOOGLE_APPLICATION_CREDENTIALS environment variable on your VM to point to the generated credentials config file.\n\nLoading...\n\nexport GOOGLE_APPLICATION_CREDENTIALS=/absolute/path/to/credentials.json\n\nYou can now start using workload identity pools to call Google APIs as illustrated in this Python snippet:\n\nLoading...\n\nfrom google.cloud import storage\n\nimport google.auth\n\nscopes=['https://www.googleapis.com/auth/cloud-platform']\ncredentials, project = google.auth.default(scopes=scopes)\n\n# Automatically initializes credentials using credentials.json config file.\nclient = storage.Client(project=project, credentials=credentials)\n# Lookup bucket information.\nbucket = client.get_bucket('test-gcs-bucket')\nprint(\"Bucket {} retrieved.\".format(bucket.name))\n\nYou can use custom attributes (claims) from the IdP to define fine-grained IAM access policy to allow or deny your workloads access to resources and audit their calls using Cloud Audit Logs.\n\nImproving your cloud security posture\n\nMoving from service account keys to the keyless application authentication mechanism enabled by workload identity federation can help you reduce the risks associated with managing long-lived keys for application authentication across your environment. With this new capability, developers can build more secure applications and better protect access to GCP services. To learn more about workload identity federation, take a look at our documentation .\n\nGoogle Cloud\n\nHelp keep your Google Cloud service account keys safe: taking charge of your security\n\nLearn best practices you can follow when managing keys in a given application environment.\n\nBy Grace Mollison • 6-minute read\n\nPosted in\n\nSecurity \u0026 Identity\n\nGoogle Cloud\n\nRelated articles\n\nSecurity \u0026 Identity\n\nAdvancing brain tumor research with privacy-first AI\n\nBy Rene Kolga • 4-minute read\n\nSecurity \u0026 Identity\n\nCloud CISO Perspectives: Why AI Threat Defense is the new boardroom baseline\n\nBy Chris Betz • 7-minute read\n\nDatabases\n\nAlloyDB adds group authentication to secure enterprise scale and AI agents\n\nBy Bjoern Rost • 4-minute read\n\nSecurity \u0026 Identity\n\nFuture-proofing data integrity: Quantum-safe digital signatures in Cloud KMS\n\nBy Matt Etemad • 5-minute read",
|
||
"content_type": "text/html",
|
||
"query": "How is Workload Identity Federation configured in GCP Cloud Storage and connected to external identity providers?",
|
||
"language": "en-US",
|
||
"round": 2,
|
||
"fetched": true,
|
||
"relevant": true,
|
||
"relevance": 1,
|
||
"source_quality": "primary",
|
||
"source_quality_score": 0.904,
|
||
"actionable": true,
|
||
"covered_gap_ids": [
|
||
"GAP-001"
|
||
],
|
||
"assessment_reason": "The article provides a direct explanation of how Workload Identity Federation is configured in GCP and how it connects to external identity providers. It outlines the steps to create a workload identity pool, connect IdPs, and grant access to resources. It also includes practical examples and commands for setting up the federation, which aligns with the concrete steps expected in the question."
|
||
}
|
||
}
|