Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatched signature when signing with impersonated credentials #1239

Closed
JesseLovelace opened this issue Aug 26, 2021 · 8 comments · Fixed by #1397
Closed

Mismatched signature when signing with impersonated credentials #1239

JesseLovelace opened this issue Aug 26, 2021 · 8 comments · Fixed by #1397
Assignees
Labels
external This issue is blocked on a bug with the actual product. priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@JesseLovelace
Copy link

A user of the cloud storage node library has reported an issue when trying to sign URLs using Workload Identity Federation. The sign url feature of the library ultimately uses GoogleAuth.sign(), so in this case I think it should be resolving to the recently implemented case for signing with impersonated credentials. Evidently, it does sign, it just produces a different signature than when the credentials and private key are used directly. Possibly some issue where the wrong email ends up getting used?

@bojeil-google
Copy link
Contributor

Are you sure they are using the expected service account for impersonation (the one they use in workload identity federation)? (the same one that has the necessary permission on the resource)

@chingor13 chingor13 added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p2 Moderately-important priority. Fix may not be included in next release. labels Aug 27, 2021
@chingor13
Copy link
Contributor

Sounds like we need to write a system test with some AWS credentials.

@bojeil-google
Copy link
Contributor

We already have an AWS integration test and a test for signBlob with workload identity federation. This issue is unlikely to be specific to AWS. We need to confirm the above before we can investigate it.

@andrewmcoupe
Copy link

Are you sure they are using the expected service account for impersonation (the one they use in workload identity federation)? (the same one that has the necessary permission on the resource)

I can confirm I am using the expected service account, yes 👍

@andrewmcoupe
Copy link

Any update on this yet?

@bojeil-google
Copy link
Contributor

Not yet. Will keep you posted.

@yoshi-automation yoshi-automation added 🚨 This issue needs some love. and removed 🚨 This issue needs some love. labels Jan 19, 2022
@shaffeeullah
Copy link

@bojeil-google do you have an estimated timeline for this work?

@bojeil-google
Copy link
Contributor

FYI @lsirac

@yoshi-automation yoshi-automation added the 🚨 This issue needs some love. label Feb 22, 2022
@sofisl sofisl added the external This issue is blocked on a bug with the actual product. label Feb 23, 2022
@yoshi-automation yoshi-automation removed the 🚨 This issue needs some love. label Feb 23, 2022
aeitzman added a commit to aeitzman/google-auth-library-nodejs that referenced this issue Apr 20, 2022
…credentials

Currently, creating signed storage URLs does not work for external account credentials because the storage library expects client_email to be returned from GoogleAuth.getCredentials(). Changing the logic so the same client email that is used to the sign the blob (extracted from the Service Account Impersonation URL) is returned from the getCredentials() call.

Fixes googleapis#1239
aeitzman added a commit that referenced this issue Apr 27, 2022
…credentials (#1397)

* fix: Fixing Implementation of GoogleAuth.sign() for external account credentials

Currently, creating signed storage URLs does not work for external account credentials because the storage library expects client_email to be returned from GoogleAuth.getCredentials(). Changing the logic so the same client email that is used to the sign the blob (extracted from the Service Account Impersonation URL) is returned from the getCredentials() call.

Fixes #1239

* addressing code review comments

* addressing code review comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external This issue is blocked on a bug with the actual product. priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
7 participants