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.

Sign up for GitHub

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

Jump to bottom

impersonated_service_account do not take into account #515

Closed
guillaumeblaquiere opened this issue Aug 23, 2021 · 9 comments
Closed

impersonated_service_account do not take into account #515

guillaumeblaquiere opened this issue Aug 23, 2021 · 9 comments

Comments

@guillaumeblaquiere
Copy link
Contributor

When you set up you user Application Default Credential with the gcloud SDK and you add a impersonated service account (command line gcloud auth application-default login --impersonate-service-account=<Service Account>), the client library don't know how to handled this authentication. It returns this error message

guillaumeblaquiere@MAC514 azure-devops-gcp % go run .                                         
google: error getting credentials using well-known file (/Users/guillaumeblaquiere/.config/gcloud/application_default_credentials.json): unknown credential type: "impersonated_service_account"

I expect a service account impersonation with my user credentials.
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Aug 23, 2021
@guillaumeblaquiere
feat: add service account impersonation support
a3dd13a 
The impersonated_service_account type in the JSON configuration file is taken into account. source_credentials field in the JSON is now supported.

Fixes golang#515
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Aug 23, 2021
@guillaumeblaquiere
refactor: make impersonateTokenSource struct public
121de73 
to impersonate the service account from the JSON config file, the existing impersonation mechanism can be reused.

Updates golang#515
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Aug 23, 2021
@guillaumeblaquiere
docs: ImpersonateTokenSource description
2fca3ad 
The refactor made ImpersonateTokenSource public. Short explanation of each fields.

Updates golang#515
@guillaumeblaquiere guillaumeblaquiere mentioned this issue Aug 23, 2021
Closed
@codyoss
Copy link
Member

codyoss commented Aug 24, 2021

Hey @guillaumeblaquiere if you are looking for service account impersonation might I recommend https://pkg.go.dev/google.golang.org/api/impersonate. That is the public version of impersonation for Google Cloud.

@guillaumeblaquiere
Copy link
Contributor Author

Hi @codyoss, I know this library but I just want to use ADC (Application Default Credential) in any case. Let me explain.

When my app run on Google Cloud, ADC use the metadata server to get credentials from a service account. When I have a permission issue, I would like to reproduce the exact behavior in my local environment, to debug locally.

However, if I use ADC as today in my local environment, I use a gcloud auth application-default login. The problem here is that I use my user credential, and not the service account credential as my service on Google Cloud platform. And I'm not able to reproduce the exact same permission issue.

A (very bad) existing solution is to download the service account key file, and to define the GOOGLE_APPLICATION_CREDENTIALS env var to use it in the ADC. Of course, and for obvious security reason, I prefer to avoid this solution.

If I use your recommended library, I need to update my code to impersonate the service account. The problem with that is that I don't reproduce exactly the same code as I have on Google Cloud, and thus the debug is not consistent.

So, the best solution is to keep the exact same code, to leverage ADC, and to use the same service account with impersonation. The gcloud CLI allows to impersonate a service account when I login gcloud auth application-default login --impersonate-service-account=....

And that's why I propose this feature support.

@codyoss
Copy link
Member

codyoss commented Sep 3, 2021

Hey @guillaumeblaquiere sorry for my slow response. I think I need to research this a little more. At least to my knowledge this is not something that we currently support broadly across the various languages. I think a change like this would need to start as an AIP addendum. Let me do a little exploring and get back to you, there might be an alternative solution that does not need any code changes.

@codyoss
Copy link
Member

codyoss commented Sep 3, 2021

It does appear that this may be supported in Java today, code. I will talk to some internal folk. I do think this is a good use-case to support but would want to make sure something like this is supported broadly. Thanks for putting this on my radar!

@codyoss
Copy link
Member

codyoss commented Sep 3, 2021

I think this is something we would like to move forward with, I don't have the time today for the review but I will try to get back to your CL sometime early next week. Thanks again for raising this use-case up!

guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Sep 4, 2021
@guillaumeblaquiere
fix: Add delegates support
c2f6109 
Get the delegates from the input JSON and use them in the refreshToken requests.

Updates golang#515
@guillaumeblaquiere
Copy link
Contributor Author

@codyoss i didn't know the AIP website and process. However, I didn't find the external_account support in it, and that's a concern if it has been implemented without being documented there (as I said, it's new for me, I might missed it)

Anyway, thank you for the Java pointer. I'm also a Java developer and I understood the code and I was able to include the delegates in a consistent way in my latest commit. There is no longer missing part in the implementation.

Have a review when you can, I would be happy to move forward with the team on it.

@guillaumeblaquiere
Copy link
Contributor Author

@codyoss Thanks for you review. I updated the code 10 days ago. Let me know what do you think and if more work is required.

@guillaumeblaquiere
Copy link
Contributor Author

@codyoss Thanks for you review and your skilled feedback on my bad "if condition". Update done.

@codyoss
Copy link
Member

codyoss commented Sep 27, 2021

@guillaumeblaquiere no worries, thats what reviews are for 😄

guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Oct 8, 2021
@guillaumeblaquiere
feat: add service account impersonation support
cb87a57 
The impersonated_service_account type in the JSON configuration file is taken into account. source_credentials field in the JSON is now supported.

Fixes golang#515
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Oct 8, 2021
@guillaumeblaquiere
refactor: make impersonateTokenSource struct public
3c21182 
to impersonate the service account from the JSON config file, the existing impersonation mechanism can be reused.

Updates golang#515
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Oct 8, 2021
@guillaumeblaquiere
docs: ImpersonateTokenSource description
224dd43 
The refactor made ImpersonateTokenSource public. Short explanation of each fields.

Updates golang#515
guillaumeblaquiere added a commit to guillaumeblaquiere/oauth2 that referenced this issue Oct 8, 2021
@guillaumeblaquiere
fix: Add delegates support
8e4ea9f 
Get the delegates from the input JSON and use them in the refreshToken requests.

Updates golang#515
@quulah quulah mentioned this issue Mar 28, 2022
Closed
nikolay-turpitko pushed a commit to nikolay-turpitko/oauth2 that referenced this issue Jan 17, 2023
@guillaumeblaquiere @nikolay-turpitko
google: add support for "impersonated_service_account" credential type.
ad72c59 
New credential type supported: "impersonated_service_account".

Extend the "credentialsFile" struct to take into account the credential source for the impersonation.

Reuse of `ImpersonateTokenSource` struct, from `google/internal/externalaccount/Impersonate.go' file. The struct has a package-scope visibility now.

Fixes: golang#515

Change-Id: I87e213be6d4b6add2d6d82b91b1b38e43a0d2fe4
GitHub-Last-Rev: 14806e6
GitHub-Pull-Request: golang#516
Reviewed-on: https://go-review.googlesource.com/c/oauth2/+/344369
Reviewed-by: Cody Oss <codyoss@google.com>
Trust: Cody Oss <codyoss@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cody Oss <codyoss@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@egnor egnor mentioned this issue Jun 18, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

google: add support for "impersonated_service_account" credential type. guillaumeblaquiere/oauth2
2 participants
@guillaumeblaquiere @codyoss