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

AIP 4110: How to retrieve tokens from the metadata server #1467

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ahmedtd
Copy link

@ahmedtd ahmedtd commented Jan 6, 2025

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.

@ahmedtd ahmedtd requested a review from a team as a code owner January 6, 2025 23:16
aip/auth/4110.md Outdated Show resolved Hide resolved
aip/auth/4110.md Outdated Show resolved Hide resolved
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

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.

aip/auth/4110.md Outdated Show resolved Hide resolved
aip/auth/4110.md Outdated Show resolved Hide resolved
aip/auth/4110.md Outdated Show resolved Hide resolved
@ahmedtd ahmedtd force-pushed the master branch 3 times, most recently from c8bd2cb to 43dcb9a Compare January 22, 2025 00:47
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.
@ahmedtd
Copy link
Author

ahmedtd commented Jan 22, 2025

@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)**
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants