IssueTracker

Hello,

Thanks for reaching out to us!

The Feature request has been created and the Product Engineering Team is working on this request. Right now, there is no ETA to this request. Thank you for your trust and continued support to improve Google Cloud Platform products.

In case you want to report a new issue, please do not hesitate to create a new Issue Tracker thread describing your issue.

Thanks & Regards,
Mahaboob

This workaround did not work for me because the command above does not expose the session expiry. Thus the application cannot use the session. I've exposed the session expiry from the token and can confirm it works.

eval $(aws sts assume-role-with-web-identity --role-arn $AWS_ROLE_ARN --role-session-name test --web-identity-token $(cat $AWS_WEB_IDENTITY_TOKEN_FILE) | jq -r '.Credentials | "export AWS_ACCESS_KEY_ID=(.AccessKeyId)\nexport AWS_SECRET_ACCESS_KEY=(.SecretAccessKey)\nexport AWS_SESSION_TOKEN=(.SessionToken)\nexport AWS_SESSION_EXPIRATION=(.Expiration)\n"')

Hello,

The Product Engineering team is aware and working on this request. Currently we cannot provide any ETA. Please follow this thread for updates.

Thanks and Regards,
Mahaboob Subhani

An option is to use the OIDC token in AWS_WEB_IDENTITY_TOKEN_FILE when using EKS. You need to set up a OIDC provider in your pool and use file-sourced credentials.

We are currently working on an SDK feature to make providing AWS creds to the library easier.

@Google team,

You have pointed back to the initial workaround mentioned by OP. What progress Google is making on this?

The option you mention to use OIDC token in AWS_WEB_IDENTITY_TOKEN_FILE is the one described in the workaround in the OP's post. i.e. You run this in the pod

eval $(aws sts assume-role-with-web-identity --role-arn $AWS_ROLE_ARN --role-session-name test --web-identity-token $(cat $AWS_WEB_IDENTITY_TOKEN_FILE) | jq -r '.Credentials | "export AWS_ACCESS_KEY_ID=(.AccessKeyId)\nexport AWS_SECRET_ACCESS_KEY=(.SecretAccessKey)\nexport AWS_SESSION_TOKEN=(.SessionToken)\nexport AWS_SESSION_EXPIRATION=(.Expiration)\n"')

When you run this command, you will have temporary AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY exported in the pod and then the Google client sdk would recognize this , and things would work as they should using the pod role instead of worker node role.

The problem is these temporary sessions expire, so how do we rotate/refresh the session effectively.

Any idea when will be the SDK feature to make providing AWS creds to the library easier would be available, any timelines ?

I am suggesting using the OIDC token directly, skipping the assume role call. To do that you would have to set up an OIDC provider in your pool and use file-sourced credential config that points to AWS_WEB_IDENTITY_TOKEN_FILE.

Can you folks please let us know which languages you'd like supported first? Thanks in advance.

So, you mean point the AWS_WEB_IDENTITY_TOKEN_FILE in credential config file. would that work?

for e.g.
  ....
  "credential_source": {
    "file": "/AWS_WEB_IDENTITY_TOKEN_FILE"
  }
  ...

I guess at first Python and Java would be mostly used.

So, you mean point the AWS_WEB_IDENTITY_TOKEN_FILE in credential config file

You can read the AWS_WEB_IDENTITY_TOKEN_FILE directly, but it is rotated very regularly so your application would. need to take that into consideration. This is what the Google SDK should be doing.

Can you folks please let us know which languages you'd like supported first?

Java for us, please.

+1 for Java here - Customer still actively wanting this.

Unless you're dealing with a large number of EKS clusters, it might be an option to federate your EKS cluster(s) with workload identity federation directly. We recently published a page that describes how to do this, see Configure workload identity federation with Kubernetes.

Is this a new feature of workload identity federation? Just trying to determine if this is a cryptic way of saying the ticket is resolved. At first glance this would remove the need for the workaround we depend on currently.

Thanks Google team, Essentially, we will establish trust with GCP that says: "trusts this openid connect (OIDC) token issued to a k8s service account by a given K8s API server and map it to this GCP principal:// or principalSet://.

While this would work for EKS , as the OIDC discovery endpoint is public (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html#:~:text=Amazon%20EKS%20hosts%20a%20public%20OIDC%20discovery%20endpoint%20for%20each%20cluster%20that%20contains%20the%20signing%20keys%20for%20the%20ProjectedServiceAccountToken%20JSON%20web%20tokens%20so%20external%20systems%2C%20such%20as%20IAM%2C%20can%20validate%20and%20accept%20the%20OIDC%20tokens%20that%20are%20issued%20by%20Kubernetes.)

But not for bare kubernetes on-prem which might be private by design. We will have make the OIDC metadata for your kubernetes cluster visible to GCP externally.

I say this, since the new post you have created titled "Kubernetes" in general. Either the title need to be EKS specific Or the caveat needs to be added for bare k8s scenario.

In addition to the approach Johannes mentioned, we have also added support recently for defining custom logic to supply the 3rd party token or AWS security credentials for workload identity federation. This feature can be used to implement logic that returns the AWS security credentials from environment variables or any other method to the google credential to exchange for a GCP access token.

• Java: https://github.com/googleapis/google-auth-library-java?tab=readme-ov-file#using-a-custom-supplier-with-aws
• Go: https://pkg.go.dev/golang.org/x/oauth2@v0.20.0/google/externalaccount#AwsSecurityCredentialsSupplier
• Python: https://googleapis.dev/python/google-auth/latest/user-guide.html#accessing-resources-using-a-custom-supplier-with-aws
• Nodejs: https://github.com/googleapis/google-auth-library-nodejs?tab=readme-ov-file#accessing-resources-from-aws-using-a-custom-aws-security-credentials-supplier