-
Notifications
You must be signed in to change notification settings - Fork 114
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
Support for workload identity federation #198
Comments
Thank you for the kind words! Unfortunately, by asking this question you already show that you know much more about this type of authentication than I do :-) Reading the docs didn't help a lot either (on first glance), as I am not very familiar with the specific feature or environments where one might use it. However, may I suggest that you (if you have the time for it) explore the source code of yup-oauth2 a bit? Maybe you find a simple way to integrate this into the existing framework, in which case I'll happily take a PR. (at which point I hopefully know a bit more about this type of authentication) |
For inspiration, it is implemented here: https://github.com/yoshidan/google-cloud-rust/tree/main/foundation/auth One, however, would have to dig deeper and understand what is what. |
Workload Identity is currently the recommended authentication mechanism on Google Kubernetes Engine: https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity#alternatives_to |
Thank you very much for this handy crate! I am wondering what would it take to add support for workload identity federation. According to the documentation,
GOOGLE_APPLICATION_CREDENTIALS
used inApplicationDefaultCredentialsAuthenticator
can point at such a file instead of a file with a service account key.The text was updated successfully, but these errors were encountered: