25 lines
7.9 KiB
JSON
25 lines
7.9 KiB
JSON
{
|
|
"schema_version": 1,
|
|
"saved_at": "2026-08-07T12:35:36.8314357Z",
|
|
"content_sha256": "1fcccc08f224bfce70a99bda4d174d348b1b88539aaf60658b88ca644a77c199",
|
|
"result": {
|
|
"title": "Understanding Workload Identity Federation and How to Configure It on Google Cloud Platform (GCP) to connect an AWS Lambda Function| ventx",
|
|
"url": "https://www.ventx.de/en/blog/gcp_workload_identity_federation/",
|
|
"snippet": "To connect an application with Google Cloud resources, we need a Service Account. Service accounts allow you to assign an identity to an application and give that identity specific permissions, such as accessing for example to Google Cloud Translation API but not to Cloud Storage bucket.",
|
|
"content": "Understanding Workload Identity Federation and How to Configure It on Google Cloud Platform (GCP) to connect an AWS Lambda Function| ventx\n\n🇩🇪\n🇺🇸\n\ninfo@ventx.de\n+49 (0) 89 416125 700\n\nUnderstanding Workload Identity Federation and How to Configure It on Google Cloud Platform (GCP) to connect an AWS Lambda Function\n\nBlog\nUnderstanding Workload Identity Federation and How to Configure It on Google Cloud Platform (GCP) to connect an AWS Lambda Function\n\n17. Okt. 2024\nCelina Inés Alsina\n\nGCP Lambda AWS OIDC Service Accounts Cloud Security Identity Managment\n\nIntroduction\n\nTo connect an application with Google Cloud resources, we need a Service Account. Service accounts allow you to assign an identity to an application and give that identity specific permissions, such as accessing for example to Google Cloud Translation API but not to Cloud Storage bucket.\n\nService account keys are similar to using passwords, allowing whoever holds them to act as the service account and access any service that the account has access to.\nTo visualize it with a daily example: If someone had the key to my house, they could enter without needing my authorization. While I could keep the key in a secure place, that location could still be vulnerable. To ensure security, I would need to rotate the location where I keep the key, and if possible, change the key periodically to avoid the problem of someone having copied it without my knowledge.\nThe same applies to an application. Unfortunately, there's no way to verify whether the application holding the key is authorized to use it, and keeping the key in a safe place becomes a secret management problem.\nThe solution to this problem is Workload Identity Federation (WIF) , which allows an application to replace the use of these non-expiring keys and verify the identity that wants to use the key. If the identification is successful instead of a key, a short-lived, one-time-use token is ussed, allowing the application to act as the service account and granting the necessary permissions.\nPrerequisites\n\nIn this post, I'm going to show how to configure WIF with an AWS Lambda function. However, this can also be configured with any provider that supports OIDC here .\nThat being said, you will need to have:\n\nAWS account\nLambda function\n\nI will guide you through the google console, but all these steps are also possible through google CLI and you can find them in the official documentation .\nFollow me through these simple 6 steps:\n\n1. Permissions:\n\nWe need to have the appropriate permissions\n\nProject creator (Needed to create a project where the identity pool will be allocated)\nOrganisation Administrator (Needed to modify two organisation policies)\n\nAfter you create the project make sure that billing is enabled.\n2. Enable APIs:\n\nGo to your project and, in the APIs section, please enable the following APIs:\n\nIAM Service Account Credentials API\nIdentity and Access Management (IAM) API\nCloud Resource Manager\nSecurity Token Service API\n\nYou can enable them by clicking here\n3. Create Service Account:\n\nIn the IAM and Admin section, create a Service Account As basic rol we need to assign Workload Identity User and additionally provide the necessary permissions for the Google resources your application will access.\n\nIn this particular case I also added the following permissions:\nresourcemanager.projects.getIamPolicy\nresourcemanager.projects.setIamPolicy\n\n4. Setting IAM Policies\n\nAlso in the IAM and Admin section, look for Organization Policies tab and there for the following policies:\n\nAllowed AWS accounts that can be configured for workload identity federation in Cloud IAM\nPolicy for Allowed external Identity Providers for workloads in Cloud IAM\n\nYou will need to provide in the first one the ID of the AWS account where your lambda is.\n\nIn the second one this value:\nhttps://sts.amazonaws.com\n\n5. Create Identity Pool\n\nGoing back to our analogy with the house keys, the identity pool would be the keyring that holds the house keys. The pool manages these keys/identities and these keys represent the different idenitty providers, in this case, AWS.\n\nNext, we have the option to configure what we want to map from the token we receive from the provider, in this case, AWS STS (Security Token Service).\nWith Github could be for example the repository name, in aws certain iam role.\n\nThe mappings shown in the image are the default ones.\nOnce created our console will look like this:\n\n6. Connecting your Lambda Function\n\nTo allow our lambda to have access to this token, we need to\n\nClick on Grant access\n\nThen select Grant access using service account impersonation\nSelect the service account previously created.\nIn the Select principals (identities that can access the service account) textarea write:\n\narn:aws:sts::[ACCOUNTD_ID]:assumed-role/[LAMBDA_ROLE_NAME]/[LAMBDA_NAME]\n\nSave it, and in the modal that opens afterward, download the generated file and upload it into your Lambda function's source folder.\n\nAnd that's it! In the Lambda code, we only need to set an environment variable named GOOGLE_APPLICATION_CREDENTIALS , with its value being the relative path to the file we downloaded in the previous step. documentation\nAs an example, the code of my lambda\nconst { ProjectsClient } = require(\"@google-cloud/resource-manager\").v3;\n\nprocess.env.GOOGLE_APPLICATION_CREDENTIALS = \"./config-file.json\";\n\nconst resourceManagerClient = new ProjectsClient();\n\nexports.handler = async function (event) {\nconst owner = event.input.employeeEmail;\nconst policy = await getsProjectPolicy(event.projectId, owner);\nconst resSetPolicy = await setNewPolicy(event.projectId, policy);\nreturn;\n};\n\nasync function getsProjectPolicy(projectId, owner) {\nconst [policy] = await resourceManagerClient.getIamPolicy({\nresource: `projects/${projectId}`,\n});\npolicy.bindings = [\nmembers: [`user:${owner}`],\nrole: \"roles/owner\",\n},\n];\nreturn policy;\n\nasync function setNewPolicy(projectId, policy) {\nconst request = {\nresource: `projects/${projectId}`,\npolicy,\n};\nconst res = await resourceManagerClient.setIamPolicy(request);\nreturn res;\n\nYou did it! 🚀\nThank you for reading my post and following along with the process of setting up Workload Identity Federation. I hope this guide was helpful and gave you a clear understanding of how powerful WIF can be when integrated into your cloud application workflows.\nLinks I used to write this article:\n\nOfficial Google Cloud Documentation\nConfigure Workload Identity Federation with AWS or Azure\nKeyless Entry: Securly Access GCP Services from Kubernetes\nHow to use Github Actions with Google's Workload Identity Federation\nWhat is Workload Identity Federation\nNodejs Google Cloud Client",
|
|
"content_type": "text/html",
|
|
"query": "Wie implementiert man Workload Identity für Cloud Service Accounts in Google Cloud?",
|
|
"language": "de-DE",
|
|
"round": 1,
|
|
"fetched": true,
|
|
"relevant": true,
|
|
"relevance": 0.7866666666666666,
|
|
"source_quality": "unknown",
|
|
"source_quality_score": 0.52,
|
|
"covered_gap_ids": [
|
|
"REVIEW-1"
|
|
],
|
|
"assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
|
|
}
|
|
}
|