bazel server caches the google default creds and won't reload them even when they're expired #23368
Comments
github-actions
bot
added
team-Core
|
This also applies to creds loaded from |
joeleba
added
P2
I could not find a way to obtain the expiration date for a google cloud token, so I was not able to provide EDIT: is possible to obtain the expiration time from inside the readonly TOKEN="$(gcloud auth print-access-token)"
# Get expiration time in RFC3339 format
readonly EXPIRY_UNIX_EPOCH="$(curl --silent "https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN}" | grep -o '"exp": *"[^"]*"' | awk -F': ' '{print $2}' | tr -d '"')"
readonly EXPIRY_RFC3339="$(date -u -r ${EXPIRY_UNIX_EPOCH} +"%Y-%m-%dT%H:%M:%SZ")"
# For context about the format of this json, see:
# * https://github.com/EngFlow/credential-helper-spec/blob/7df9bef60ef05636fd93114a17a7b2ea08143af6/schemas/get-credentials-response.schema.json
# * https://github.com/EngFlow/credential-helper-spec/blob/7df9bef60ef05636fd93114a17a7b2ea08143af6/spec.md
# * https://github.com/bazelbuild/bazel/blob/222d47f3bd57370f9a462ebdd86dfe1510795cd2/src/main/java/com/google/devtools/build/lib/authandtls/credentialhelper/GetCredentialsResponse.java
cat << EOF
{
"headers": {
"Authorization": ["Bearer ${TOKEN}"]
},
"expires": "${EXPIRY_RFC3339}"
}
EOF |
|
Also it looks like, if using Changing to: Does not have effect: the credential stays cached. Will only take effect after running |
|
(Filed a separate issue to keep the discussion here focused on |
Description of the bug:
It seems like the bazel server won't refresh the creds generated from
--google_default_credentialseven when they're invalid. This seems to apply to both the normal expiration process and the artificial expiration process (early revocation) that I've documented below in the repro (it's just easier to see it in a reasonable amount of time using revocation instead of waiting for expiration)Which category does this issue belong to?
Core, Remote Execution
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Which operating system are you running Bazel on?
linux (ubuntu 22.04)
What is the output of
bazel info release?release 7.3.0
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.n/a
What's the output of
git remote get-url origin; git rev-parse HEAD?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
This seems to be similar (or maybe the same?) as these issues:
Any other information, logs, or outputs that you want to share?
The generated warnings are:
The text was updated successfully, but these errors were encountered: