Docs: What is the purpose of `project_id` when using Workload Identity Federation?

[reakaleek]

In the example https://github.com/google-github-actions/auth/blob/main/docs/EXAMPLES.md#configuring-gcloud, you add the project_id attribute.

Is it only there to export it as environment variables and set the output for subsequent actions?

We recently had a case where we unintentionally put the wrong project_id. The workflow was still working; we only noticed because of a discussion.

But we were wondering if there should be a warning if there is a mismatch in the project_id and the workload_identity_provider's project number.

WDYT?

[github-actions]

Hi there @reakaleek 👋!

Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps.

[sethvargo]

It sets the environment variables so downstream tools properly infer the project ID. Additionally it's required if you try to mint any kind of non-federated token (but we can infer it from the service account if given).

[sethvargo]

But we were wondering if there should be a warning if there is a mismatch in the project_id and the workload_identity_provider's project number.

There is a warning printed, but it's printed at info instead of warning because people complained about cluttered logs. Additionally, project_id and project_number are different, and we don't require permissions on the translation service to determine if the project_number in the WIF provider corresponds to the project_id. If we expanded to include that permission, we could infer the project_id from the project_number with an additional API call, but it would break many existing uses that don't grant the federated token cloudresourcemanager permissions.

[reakaleek]

Thank you for the elaborate explanation.