No explanation and little guidance around setting up roles/iam.serviceAccountTokenCreator lead to frustration.
We use BQ a lot in our Org. I have built many apps using the BQ APIs and auth has always been easy. Provide token file and you're done.
Now we wanted to insert some data into BQ during CI and I was very confused with how complicated the setup is. I needed to enable the IAM feature and I needed to grant an additional permission.
First of all what would have lowered my frustration would have been a paragraph in the docs explaining to me the reason why something that was very easy before (just token JSON and done) now requires so much setup.
Secondly, it was very hard to find out how to set the roles/iam.serviceAccountTokenCreator. You do document that this permission needs to be set for the service acc on itself, but being the mindless sheep that I am I did go to https://console.cloud.google.com/iam-admin/iam first. Judging from the name roles/iam.serviceAccountTokenCreator I was looking for some kind of token creator under the IAM role menu. Luckily I didn't find it there, so I went back to the docs and noticed the note "on itself". So I went to https://console.cloud.google.com/iam-admin/serviceaccounts and looked again and still didn't find anything under IAM. Frustration maximizes. Somehow I stumbled accross Service Accounts roles and found Service Account Token Creator there. That did it. But it was quite the hunt.EDIT: going back and extracting my explanation from the above md block:
We use BQ a lot in our Org. I have built many apps using the BQ APIs and auth has always been easy. Provide token file and you're done.
Now we wanted to insert some data into BQ during CI and I was very confused with how complicated the setup is. I needed to enable the IAM feature and I needed to grant an additional permission.
First of all what would have lowered my frustration would have been a paragraph in the docs explaining to me the reason why something that was very easy before (just token JSON and done) now requires so much setup.
Secondly, it was very hard to find out how to set the roles/iam.serviceAccountTokenCreator. You do document that this permission needs to be set for the service acc on itself, but being the mindless sheep that I am I did go to https://console.cloud.google.com/iam-admin/iam first. Judging from the name roles/iam.serviceAccountTokenCreator I was looking for some kind of token creator under the IAM role menu. Luckily I didn't find it there, so I went back to the docs and noticed the note "on itself". So I went to https://console.cloud.google.com/iam-admin/serviceaccounts and looked again and still didn't find anything under IAM. Frustration maximizes. Somehow I stumbled accross Service Accounts roles and found Service Account Token Creator there. That did it. But it was quite the hunt.
No response
Hi @pofl
Thank you for opening an issue. First, you can still authenticate using exported service account key JSON files using this GitHub Action. If that is your preferred method for authentication, you can continue to use that on CI. As documented there, we recommend using Workload Identity Federation instead, because downloading a service account key JSON creates a long-lived credential, and anyone with that credential can authenticate as the principal. If you think that risk is acceptable to your project, you can still download and export keys.
However, there are many GCP customers who have recognized the pitfalls of exported service account keys and created org policies to disable them entirely. That means users can't create those keys, so they need another way to authenticate - Workload Identity Federation.
With Workload Identity Federation, you're granting an external identity (represented via principalSet://<uri>) access to GCP resources, so you give the external identity access to impersonate the service account. This requires the Service Account User or Service Account Token Creator role, depending on your use case.
First, you can still authenticate using exported service account key JSON files using this GitHub Action. If that is your preferred method for authentication, you can continue to use that on CI.
I did find that section of the readme. I still need to grant a special permission. Granting this role was hard to figure out and given how high quality and extensive the readme is, I figured you might want to add some guidance and explanation to the readme.
| Owner Name | google-github-actions |
| Repo Name | auth |
| Full Name | google-github-actions/auth |
| Language | TypeScript |
| Created Date | 2021-09-16 |
| Updated Date | 2023-03-24 |
| Star Count | 573 |
| Watcher Count | 16 |
| Fork Count | 116 |
| Issue Count | 3 |
| Issue Title | Created Date | Updated Date |
|---|