Commit a24ae0f4 authored by xuwang's avatar xuwang
Browse files

fix(gcp-login): drop GSA_NAME assertion in workload-identity login 



GSA_NAME may legitimately be set for an unrelated task (e.g. FUSE vs
CICD jobs), so asserting the metadata SA matches it caused spurious
workload-identity login failures. The branch still fails loudly when the
metadata identity is not a bound GSA (bare pool identity / default
compute SA), which is the case that actually matters. Also corrects the
stale header comment that claimed WI is auto-detected.

Changelog: fixed
Co-Authored-By: default avatarClaude Opus 4.8 <noreply@anthropic.com>
parent ff2306a8

scripts/gcp-login.sh

+2 −7
Original line number Diff line number Diff line
@@ -5,7 +5,8 @@ 
#   device             headless OAuth via device code

#   service            activate a service account key file

#   workload-identity  GKE Workload Identity — credentials injected by the

#                      metadata server; also auto-detected when on GKE

#                      metadata server; must be requested explicitly (never

#                      auto-detected, see NOTE below)



command -v gcloud > /dev/null || { echo "gcloud CLI is not installed."; exit 1; }
@@ -45,12 +46,6 @@ case "${auth_method}" in 
            echo "       Workload Identity is not configured for this pod's KSA."

            exit 1

        fi

        # When GSA_NAME is set, verify the metadata identity matches the expected SA.

        if [[ -n "${GSA_NAME}" && "${_detected_email}" != "${GSA_NAME}@"* ]]; then

            echo "ERROR: GKE metadata SA (${_detected_email}) != GSA_NAME=${GSA_NAME}."

            echo "       Workload Identity may not be configured for this pod's KSA."

            exit 1

        fi

        echo "Workload Identity: running as ${_detected_email}."

        ;;