Add selective retries for STS token exchange - #532
Merged
kkarrenn merged 2 commits intoJul 29, 2026
Merged
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
blalor
marked this pull request as ready for review
July 21, 2026 17:36
blalor
marked this pull request as draft
July 21, 2026 18:39
blalor
marked this pull request as ready for review
July 21, 2026 21:00
kkarrenn
reviewed
Jul 24, 2026
kkarrenn
reviewed
Jul 24, 2026
kkarrenn
requested changes
Jul 24, 2026
kkarrenn
left a comment
There was a problem hiding this comment.
Thank you for this PR! Added a couple of comments below.
Contributor
Author
|
Updated. Thank you @kkarrenn! |
kkarrenn
approved these changes
Jul 29, 2026
aanm
added a commit
to cilium/cilium
that referenced
this pull request
Aug 31, 2026
Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
41ks
pushed a commit
to DataDog/cilium
that referenced
this pull request
Aug 31, 2026
Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
kaworu
pushed a commit
to kaworu/cilium
that referenced
this pull request
Sep 3, 2026
[ upstream commit e85c8c4 ] Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
github-merge-queue Bot
pushed a commit
to cilium/cilium
that referenced
this pull request
Sep 3, 2026
[ upstream commit e85c8c4 ] Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
nobiit
pushed a commit
to nobidev/cilium
that referenced
this pull request
Sep 4, 2026
[ upstream commit e85c8c4 ] Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
nobiit
pushed a commit
to nobidev/cilium
that referenced
this pull request
Sep 4, 2026
[ upstream commit e85c8c4 ] Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
henrik242
added a commit
to henrik242/gha-meta
that referenced
this pull request
Sep 10, 2026
The STS exchange in google-github-actions/auth has no retry of its own and occasionally fails with ECONNRESET. Fixed upstream in google-github-actions/auth#532, but not in any release yet.
sypakine
pushed a commit
to sypakine/cilium
that referenced
this pull request
Sep 25, 2026
Every GCP-touching workflow dies outright when one TCP connection is lost in the "Set up gcloud credentials" step. google-github-actions/auth writes the credentials file locally, then makes a single Workload Identity token exchange against sts.googleapis.com as a misconfiguration pre-flight whose auth_token output no cilium workflow reads. That POST has no fault tolerance: the action asks @actions/http-client for allowRetries with maxRetries 3, but the client grants retries only to OPTIONS, GET, DELETE and HEAD, and even then only on a 502, 503 or 504 response, never on a socket error. A reset therefore ends authentication on the first attempt, before any cluster is created. In https://github.com/cilium/cilium/actions/runs/33262413149/job/99126603998 the KPR+IPsec leg died 61 ms after writing the credentials file, with every step from cluster creation to the connectivity test reported as skipped. Upstream fixed this in google-github-actions/auth#532, merged on 2026-07-29, but cut no release: v3 and v3.0.0 both still resolve to the commit three before it, so the tag-following auto-merge-trusted-deps group can never reach the fix. Move the pin at all eleven call sites onto 12060449e872, whose dist bundle carries the rebuilt fix and whose only other delta over v3.0.0 is two README edits and a checkout bump in the action's own CI. A misconfigured provider or an unbound service account still fails on the first attempt. Renovate needs the ignoreDeps entry because pinDigests plus that group membership would otherwise re-pin down to the newest tag and silently revert this. It goes away once upstream tags a release above v3.0.0. This commit was prepared with AIL:3. I personally checked the upstream dist bundles at both pins. Signed-off-by: André Martins <andre@cilium.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The workload identity flow retries GitHub OIDC token retrieval, but
@actions/http-clientdoes not retry the POST to Google Security Token Service. A transient connection reset or socket timeout therefore ends authentication on the first failed exchange.This change adds four bounded STS attempts with 100, 200, and 400 ms backoffs. Retries are limited to connection failures and HTTP 408, 429, 500, 502, 503, and 504 responses. HTTP 400, 401, 403, empty responses, and unknown errors fail without retrying.
Attempt diagnostics contain only the operation, STS hostname, status or classified error, and attempt count. The existing STS request and computed-audience debug messages were removed so these diagnostics do not include the OIDC assertion, returned access token, headers, credential data, service account, or workload identity provider resource.
Mocked tests cover each retryable HTTP status, connection errors, the uncoded
@actions/http-clientsocket timeout, permanent HTTP failures, the four-attempt limit, and diagnostic redaction.