-
Notifications
You must be signed in to change notification settings - Fork 453
Description
Hello everyone,
I have a GKE standard cluster where I deployed a PHP workload that needs to generate GCS Signed URLs via the google/cloud-storage library (updated to the latest version - 1.48.1).
Initially, I just followed the GKE docs recommendations and set up Workload Identity Federation to define IAM bindings directly between the GCS bucket and my k8s pod ServiceAccount. This solution wasn't working: normal access to the bucket was ok, but signed URLs weren't being generated.
At this point, I found indication in the docs that this particular use case wasn't supported by Workload Identity Federation (because no private key is involved in this configuration), so I decided to switch to granting permissions on the bucket to a normal IAM service account, and then linking this SA to my pod k8s ServiceAccount via the roles/iam.workloadIdentityUser role and the correct annotation on the k8s ServiceAccount.
Still, something wasn't working: the pod had access to the bucket, but signed URLs generation was failing with the error Permission 'iam.serviceAccounts.implicitDelegation' denied on resource (or it may not exist).
After a long trial and error, I got it to work by keeping this last configuration and adding another IAM binding, where I gave the roles/iam.serviceAccountTokenCreator role to the IAM SA on itself.
So, to sum up:
roles/iam.workloadIdentityUser- target: IAM service account
- principal: k8s ServiceAccount
roles/iam.serviceAccountTokenCreator- target: IAM service account
- principal: IAM service account
- k8s annotation on the ServiceAccount to indicate the IAM SA to impersonate
Since this seems really convoluted and not well documented at all, I'm wondering if it is actually the right way to cover my use case and if it is considered a standard practice.