Closed sethvargo closed 1 year ago
Is there further reading here? The direct vs service princiapl distinction isn't mentioned anywhere I've seen
It's a new feature and it seems to be mostly undocumented at the moment. It is implied by the documentation here: https://cloud.google.com/iam/docs/principal-identifiers#v1\
Effectively, it is now possible to authorize a workload/workforce identity pool principal directly, without the need to impersonate a service account. It is broadly supported across GCP products, but not yet completely, which may explain the lack of documentation at the moment.
However, not all Google Cloud resources support principalSet identities.
I am currently seeking clarification regarding the specific Google Cloud resources that do not support principalSet identities. Unfortunately, I have not been able to find detailed information on this topic in the official Google Cloud documentation. The README.md states it as 'Preferred', and I am interested in using it. However, I am having trouble because the range of resources that can be utilized remains unclear.
@sethvargo
After this PR, this bit in the README is misleading/incomplete:
project_id: (Optional) Custom project ID to use for authentication and exporting into other steps. If unspecified, the project ID will be extracted from the Workload Identity Provider or the Service Account Key JSON.
This makes it seem like if you specify workload_identity_provider
by itself, it will be able to extract the project ID, but that seems to not be the case — it only knows how to get it from the service account email address (which is now option), not the workload_identity_provider
itself. I think this is just a doc issue (you can't get the project ID from the workload_identity_provider
because project ID is a name and workload_identity_provider
seems to require the project number).
After this PR, this bit in the README is misleading/incomplete...
This adds a new authentication mode, Direct Workload Identity Federation. This new mode permits authenticating to Google Cloud directly using the GitHub Actions OIDC token instead of proxying through a Google Cloud Service Account.