-
Notifications
You must be signed in to change notification settings - Fork 524
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
AIP 4110: How to retrieve tokens from the metadata server #1467
base: master
Are you sure you want to change the base?
Conversation
aip/auth/4110.md
Outdated
Instead, you should maintain an in-memory cache of the access token, and use the | ||
cached token across all of your outbound requests. | ||
|
||
**Use a robust refresh strategy:** Each time you attempt to use the cached |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Google Auth golang 0.6.0 (googleapis/google-cloud-go#10426) supports this non-blocking token refresh feature. If they can't use Google SDK for some reason, they can take it as an example for their implementation.
c8bd2cb
to
43dcb9a
Compare
Add a complete discussion of how auth libraries and workloads should cache and refresh tokens when loading them from the metadata server. Existing GCP auth libraries handle this properly, but occasionally it is not possible or desirable to use a preexisting auth library. This new section of the AIP provides guidance for those who need to directly retrieve tokens.
@sai-sunder-s This is ready for another review pass |
@@ -133,7 +144,7 @@ digraph d_front_back { | |||
1. If the credential is [an external account][8] JSON, go to step (4) | |||
1. If the credential is unknown type, return an error saying that _[END]_ | |||
1. Credentials not found _[END]_ | |||
1. **Check workload credentials (on GCE, GKE, GAE and Serverless)** | |||
1. **Check workload access token (on GCE, GKE, GAE and Serverless)** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the sub points talk about id token. So better to keep this as credentials?
Request: `GET | ||
http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/identity`. | ||
Accepts the following query parameters: | ||
* `audience` (Required): The audience for which this token should be issued. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can ask for any audience?
|
||
**Use a robust refresh strategy:** Each time you attempt to use the cached | ||
access token, check the remaining lifetime of the token. | ||
* If it is greater than 225 seconds, the token is fresh. Proceed to use it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the reasoning behind 225?
Certain implementations of the metadata server use the "Background Refresh" | ||
strategy described above for managing their own internal caches of tokens. For | ||
example, when running on GKE with Workload Identity Federation for GKE enabled, | ||
gke-metadata-server will not reliably return a refreshed access token until 120 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we will get back stale token until 2 mins before expiry, why should we try refresh 225 secs before expiry?
Add a complete discussion of how auth libraries and workloads should cache and refresh tokens when loading them from the metadata server.
Existing GCP auth libraries handle this properly, but occasionally it is not possible or desirable to use a preexisting auth library. This new section of the AIP provides guidance for those who need to directly retrieve tokens.