documentation misleading for Application Default Credentials

[eeaton]

TL;DR

Documentation is confusing about Application Default Credentials, implying they can only be used with self-hosted runners in a GCP environment. This is inaccurate because the other methods, including WIF and service account, also set ADC.

setup-gcloud/README.md

Line 168 in 87fba63

If and only if you are using self-hosted runners that are hosted on Google Cloud Platform,

Expected behavior

If and only if you are using self-hosted runners that are hosted on Google Cloud Platform,
the Cloud SDK will automatically authenticate using the machine credentials:

This statement is misleading because Application Default Credentials are set by 'google-github-actions/auth@v2' with the provided credentials, and the statement implies that the only way to use ADC is with a self-hosted runner.

Observed behavior

My tests demonstrate that ADC is already set using Workload Identity Federation after 'google-github-actions/auth@v2'.
I can run a python script using Python Cloud Client Libraries that correctly authenticates as the service account configured by WIF, and the client Libraries rely on ADC for authentication.

Suggested fix:

• It would be more accurate to rename this "Application Default Credentials" section to something like "credentials from a service account attached to the runner". All the other methods under the Authorization header set both gcloud and ADC credentials.
• Add text under the Authorization header like: "The google-github-actions/auth action configures both gcloud credentials and Application Default Credentials"

Action YAML

name: wif-ci
on:
  [push, pull_request, workflow_dispatch]
jobs:
  actions_with_wif_token:

    runs-on: ubuntu-latest

    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: 'authenticate using WIF'
      uses: 'google-github-actions/auth@v2'
      with:
        workload_identity_provider: 'projects/$NUMBER/locations/global/workloadIdentityPools/$POOL/providers/$PROVIDER'
        service_account: '$SA_EMAIL'

    - name: 'Set up Cloud SDK'
      uses: 'google-github-actions/setup-gcloud@v2'
      with:
        install_components: 'bq'

    - name: 'confirm if gcloud cli is authenticated'
      run: 'gcloud compute instances list'

    - name: 'install python'
      uses: actions/setup-python@v5
      with:
        python-version: '3.10'
        cache: 'pip' # caching pip dependencies

    - name: 'install python dependencies'
      run: 'pip install google-cloud-bigquery==3.19.0'

    - name: 'run a python script with client libraries that relies on Application Default Credentials'
      run: 'python src/query.py'

Log output

No response

Additional information

No response

[sethvargo]

Hi @eeaton - this isn't entirely correct.

1. setup-gcloud does NOT configure ADC. It installs gcloud and, if the ADC exported from auth exists in the environment, it authenticates with that. gcloud auth login --cred-file does not set ADC (it would need --update-adc to do that), and this was an intentional decision to only authenticate gcloud locally and defer ADC management to auth, since not all actions and commands use gcloud.

2. gcloud does not actually read ADC ($GOOGLE_APPLICATION_CREDENTIALS), so there's some sharing we do with a special envvar between the two actions. On Google Cloud, gcloud will read from the metadata server to get its ADC.

[eeaton]

Sorry if my initial phrasing was unclear.

re #1, I understand that the setup-gcloud action does not configure configure credentials, it is the auth action that configures credentials. I'll revise the suggested text in the PR to avoid ambiguity about which action is being discussed.

The text that is likely to be misinterpreted is:

###Application Default Credentials : If and only if you are using self-hosted runners that are hosted on Google Cloud Platform, the Cloud SDK will automatically authenticate using the machine credentials

A reader who needs to run code on a client library, which will pick up the credentials provided by ADC, is likely to misinterpret this to mean the client library can only be authenticated if they setup self-hosted runners on GCP. I understand the intent here was to say "When you're using a self-hosted runner, both gcloud and ADC automatically get their credentials from the GCE metadata server based on the attached service account", but as written it's ambiguous.

The actual behavior is that they could authenticate the code on client library (ADC) using any of the listed options for the auth action (WIF, service account key, or service account attached to a self-hosted runner, etc).

[sethvargo]

Ya, correct 😄

[sethvargo]

#686