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

How can I authenticate using Workload identity federation? #354

Open
MrPhantomT opened this issue Nov 17, 2021 · 16 comments
Open

How can I authenticate using Workload identity federation? #354

MrPhantomT opened this issue Nov 17, 2021 · 16 comments
Labels
api: drive Issues related to the Drive API API. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@MrPhantomT
Copy link

Hello, I'm trying to authenticate access to Google Drive from my AWS EC2 instance using Workload Identity Federation, but unfortunately can't figure how to do it.

Is that library support such authentication? Any plans to support it?

Thanks.

@MrPhantomT MrPhantomT changed the title How can I authenticate using Workload identity federation How can I authenticate using Workload identity federation? Nov 17, 2021
@quartzmo
Copy link
Member

quartzmo commented Nov 17, 2021

@MrPhantomT In your EC2 instance, will you obtain a short-lived OAuth 2.0 access token as described in Workload Identity Federation - Service account impersonation? If so, I recently added minimal support for using a token that is obtained externally in v1.1.0. Usage example is shown in issue #346. Will that work for you? If not, we can investigate how to support the entire flow.

@MrPhantomT
Copy link
Author

@quartzmo No, I don't have any short-lived token.

Basically I have tried to follow that guide trying to allow usage of Google Drive API from AWS EC2 instance that has specific role assigned without obtaining.

Thanks.

@quartzmo
Copy link
Member

Is this the relevant part of the guide?

To allow the use of AWS security credentials, you must configure the workload identity pool to trust your AWS account. Security credentials tokens issued for this AWS account are then recognized by workload identity federation, and you can use the tokens to obtain short-lived service account credentials.

@MrPhantomT
Copy link
Author

Yes, but in implementation of that library for other languages like python, node it's looks like all steps(parsing of configuration.json file, obtaining of AWS security token) done inside.

@quartzmo
Copy link
Member

If it's not too much trouble, can you link to where its done in Python and Node?

@MrPhantomT
Copy link
Author

The next section in the documentation of Node library describes usage: Using External Identities
I have tracked code up to the next file where all obtaining logic implemented.

I have a little bit troubles with python but I guess this file implement all logic and I guess this part of documentation cover it.

@quartzmo
Copy link
Member

Thank you for these links, that is very helpful. It sounds like you would like to see equivalent feature support in this library?

@MrPhantomT
Copy link
Author

Yes, it would be great.

@yoshi-automation yoshi-automation added triage me I really want to be triaged. 🚨 This issue needs some love. labels Nov 18, 2021
@meredithslota meredithslota added api: drive Issues related to the Drive API API. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. and removed triage me I really want to be triaged. 🚨 This issue needs some love. labels Feb 17, 2022
@hermanbanken
Copy link

If we use https://github.com/google-github-actions/auth today with this library (via Fastlane) we get an error:

missing client_email

which is thrown here:

The JSON Key generated by https://github.com/google-github-actions/auth has this format:

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/default/providers/github",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-name.iam.gserviceaccount.com:generateAccessToken",
  "credential_source":
    {
      "url": "https://pipelines.actions.githubusercontent.com/some-long-path/idtoken?api-version=2.0&audience=https%3A%2F%2Fiam.googleapis.com%2Fprojects%2F1234567890%2Flocations%2Fglobal%2FworkloadIdentityPools%2Fdefault%2Fproviders%2Fgithub",
      "headers": { "Authorization": "***" },
      "format": { "type": "json", "subject_token_field_name": "value" },
    },
}

So no client_email is present. I think this library should add support for this format, just like all the other Google Auth libraries, which gained support in begin of last year:

@hermanbanken
Copy link

Note that libraries like https://github.com/google-github-actions/auth can also generate the OAuth Access Token, so in principal there is no need to understand the external_account JSON Key format for most use cases, as long as a pre-populated OAuth Access Token could be used.

@rbclark
Copy link

rbclark commented Apr 19, 2022

Is this still on the table to be implemented and is there a timeline? I'd really like to leverage Workload Identity Federation however this library lacking support is a bit of a blocker to that since the upstream tools I am leveraging use this library directly.

I currently am trying to use a external_account.json to connect but am receiving the error:

Unable to read the credential file specified by GOOGLE_APPLICATION_CREDENTIALS: credentials type 'external_account' is not supported

This error is coming from https://github.com/googleapis/google-auth-library-ruby/blob/main/lib/googleauth/default_credentials.rb#L57 which makes sense since the library has not yet implemented it.

@hermanbanken
Copy link

@quartzmo do you know if this is a topic that this library is accepting contributions for?

(I'm not comfortable with Ruby, but others in this thread might be more equipped to contribute. Just want to move this thread/feature forward.)

@rbclark
Copy link

rbclark commented Apr 20, 2022

@quartzmo I am quite comfortable with Ruby and would be willing to take a stab at this if it is something the library would entertain merging.

@corytheboyd-smartsheet
Copy link

corytheboyd-smartsheet commented Mar 2, 2023

Just throwing in my "this would be really really really nice to have in the Ruby SDK". Workload identity federation is going to be huge for us, as we are very multi-cloud with primary services hosted on GCP. Huge thanks to @rbclark for taking one for the team running the PR 😄

@shivgautam
Copy link
Contributor

Hi, The team is working on it and will post an update soon. We don't have an ETA but it is being actively worked upon and should be ready soon. Thank you all for your patience.

@w32-blaster
Copy link

We are trying to use the newly released library with workload identity federation to GCP and seeing the following problem:
When authenticating from an EC2 instance this works now great with the version 1.5.0 (#418)

The problem is when a workload is running on an EKS cluster with irsa, the normal authentication flow through the metadata service does not work, so WIF can be only used with generic OIDC provider. In this case the subject_token_type and the whole configuration looks different:

"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "file": "/var/run/secrets/eks.amazonaws.com/serviceaccount/token",
    "format": {
      "type": "text"
    }
  }

It would be great to support the EKS service accounts as well, and not just EC2 and metadata provided token based auth.

Let me know if that should go to a different feature request.

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

Successfully merging a pull request may close this issue.

9 participants