Using workload Identity federation AWS ECS

Google Cloud Compute Infrastructure
1

How would one go about setting up workload identity federation for AWS ECS (container service)?

IMDS url for EC2 instance - http://169.254.169.254/latest/meta-data/iam/security-credentials

URL for ECS - http://169.254.170.2/get-credentials

When I try to use the config file that’s generated after setting up WIF as per Google docs, I see “Failed to retrieve AWS credentials” exception in my application running on AWS ECS.

I used java gcp sdk to retrieve google credentials -

String base64EncodedGCPCredentials = credentialsMap.get(“base64EncodedGCPCredentials”)

GoogleCredentials credentials = GoogleCredentials.fromStream(new ByteArrayInputStream(Base64.getDecoder().decode(base64EncodedGCPCredentials)));

Dns dns = DnsOptions.newBuilder()
.setCredentials(credentials)
.setProjectId(projectId)
.build()
.getService();

Any pointers on how to handle authentication using WIF with AWS ECS?

2 Likes
2

Hi @TridentChase .,

have you followed the GCP official documentation?
→ https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds

2 Likes
3

Hi @MaxImbrox ,

Yes I did. I see this 403 error when I try to use the service :

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/cloud-dns@gcp-tcore.iam.gserviceaccount.com:generateAccessToken

{
  "error": {
   "code": 403,
   "message": "Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).",
   "errors": [
    {
     "message": "Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).",
     "domain": "global",
     "reason": "forbidden"
    }
   ],
   "status": "PERMISSION_DENIED",
   "details": [
    {
     "@type": "type.googleapis.com/google.rpc.ErrorInfo",
     "reason": "IAM_PERMISSION_DENIED",
     "domain": "iam.googleapis.com",
     "metadata": {
      "permission": "iam.serviceAccounts.getAccessToken"
     }
    }
   ]
  }
 }

The service account being used does have iam.serviceAccounts.getAccessToken and I’ve double checked it.

2 Likes
4

Has anyone found a solution to this?
I am having the same problem

2 Likes
5

We used the below steps to fix the issue :

  1. Set attribute.aws_role in attribute mapping to assertion.arn.extract(‘assumed-role/{role}/’)
  2. Set attribute.aws_role=“career-ecs”

We noticed that for ecs, when getCallerIdentity is called, it returns career-ecs as the assumed role.

P.S we used service account impersonation

2 Likes
6

Is this response still valid today?