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

idtoken: Can't use impersonated service account token #1393

Closed
j0hnsmith opened this issue Jan 12, 2022 · 10 comments
Closed

idtoken: Can't use impersonated service account token #1393

j0hnsmith opened this issue Jan 12, 2022 · 10 comments
Assignees
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@j0hnsmith
Copy link

j0hnsmith commented Jan 12, 2022

Environment details

  • Programming language: Go
  • OS: all
  • Language runtime version: all
  • Package version: v0.65.0

Steps to reproduce

  1. authClient, err := idtoken.NewClient(ctx, endpoint)

Problem

Trying to use an impersonated_service_account token doesn't work because only tokens with type service_account are supported.

if f.Type != "service_account" {
return fmt.Errorf("idtoken: credential must be service_account, found %q", f.Type)
}

Anywhere a service account can be used an impersonated service account should also be valid. I'm getting the error idtoken: credential must be service_account, found "impersonated_service_account"

@j0hnsmith j0hnsmith added 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. labels Jan 12, 2022
@codyoss
Copy link
Member

codyoss commented Jan 12, 2022

Are you trying to create an idtoken from an impersonated service account? If so I would recommend this method in the impersonate package: IDTokenSource.

@codyoss codyoss added type: question Request for information or clarification. Not an issue. and removed 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. labels Jan 12, 2022
@codyoss codyoss changed the title Can't use impersonated service account token (idtoken) idtoken: Can't use impersonated service account token Jan 12, 2022
@j0hnsmith
Copy link
Author

No, I want an "HTTP Client that automatically adds an ID token to each request via an Authorization header". I know there are other token source implementations however idtoken.NewClient() explicitly does't support option.WithTokenSource (see below).

// NewClient creates a HTTP Client that automatically adds an ID token to each
// request via an Authorization header. The token will have have the audience
// provided and be configured with the supplied options. The parameter audience
// may not be empty.
func NewClient(ctx context.Context, audience string, opts ...ClientOption) (*http.Client, error) {
var ds internal.DialSettings
for _, opt := range opts {
opt.Apply(&ds)
}
if err := ds.Validate(); err != nil {
return nil, err
}
if ds.NoAuth {
return nil, fmt.Errorf("idtoken: option.WithoutAuthentication not supported")
}
if ds.APIKey != "" {
return nil, fmt.Errorf("idtoken: option.WithAPIKey not supported")
}
if ds.TokenSource != nil {
return nil, fmt.Errorf("idtoken: option.WithTokenSource not supported")
}

The exact functionality I want is provided by idtoken.NewClient()... apart from impersonated_service_account tokens not being valid.

@j0hnsmith
Copy link
Author

@codyoss Hi, I see you changed the label to question, I'm confused, at the least this is a feature request, no?

If you think that idtoken.NewClient(ctx, endpoint) shouldn't work with an impersonated service account can you give a reason why?

@guillaumeblaquiere
Copy link

I have finished to work on that feature and I discovered that thread. The impersonated service account credential type definitively must be able to generate an id_token on the service account that is impersonated.

use case: I want to invoke a Cloud Run IAM protected from my dev environment. I can't generate a service account key file (Organisation policy set, and in any case, it's a bad practice), and I don't want to change my code (to make it working exactly in the same way on GCP).

However, for that, a fix is required on my previous contribution in the golang.org/x/oauth2 library (here my pull request to set a default scope is no scope is defined).

To have an overview of a working solution, here my current commit that work with the fix. I will create a pull request as soon as the fix is merged.

@codyoss codyoss added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. and removed type: question Request for information or clarification. Not an issue. labels Jan 21, 2022
@bombsimon
Copy link

I have a similar problem but with external_account rather than impersonated_service_account.

I have a Workload Identity Federation setup and am using Keyless API authentication, basically just setting GOOGLE_APPLICATION_CREDENTIALS to the path of my JSON file without credentials. This works fine when using access tokens (FindDefaultCredentials) which you do for most SDK clients and services, however I also use IAP which obviously requires an ID token.

My first question would be if this is even intended to be supported, that is to get an ID token for an external_account?

If so, would my issue be included in the scope for this issue or should I open a new one? Or is there in fact a way for me to actually get a token source that returns ID tokens since I also need to create a client that automatically sets a valid token on each request. I looked into impersonate.IDTokenSource but did not get that to work, is it expected to work with external_account?

@senthilkumarkj
Copy link
Contributor

I hit the same problem described above. Is there a solution?

@codyoss
Copy link
Member

codyoss commented Jan 6, 2023

This is now supported as of #1792

@codyoss codyoss closed this as completed Jan 6, 2023
@senthilkumarkj
Copy link
Contributor

looks like the above PR added support only for type impersonated_service_account but not type external_account used in workload identity https://google.aip.dev/auth/4117

@codyoss
Copy link
Member

codyoss commented Feb 27, 2023

@senthilkumarkj That was intentional as the original issue was about impersonated_service_account. external_account should be a new different issue to be tracked.

@senthilkumarkj
Copy link
Contributor

Thanks, Cody. Opened new issue to track it - #1879. Without this we are unable to call Cloud Run APIs in Google Cloud from a non google platform with Workload Identity Federation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

5 participants