Hello,
It seems impersonation through cloudbuild does not work (or by design) at least on some gcloud commands.
Did some test (simulating errors to understand who's making the call), the 2nd error shows that the the cloudbuild role is making the call despite using impersonation. 1st call is expected though.
Updated property [auth/impersonate_service_account].
WARNING: This command is using service account impersonation. All API calls will be executed as [deploy@prj-b.iam.gserviceaccount.com].
ERROR: (gcloud.storage.ls) HTTPError 403: deploy@prj-b.iam.gserviceaccount.com does not have storage.buckets.list access to the Google Cloud project. Permission 'storage.buckets.list' denied on resource (or it may not exist).
WARNING: This command is using service account impersonation. All API calls will be executed as [deploy@prj-b.iam.gserviceaccount.com].
ERROR: (gcloud.secrets.list) User [cloudbuild@prj-a.iam.gserviceaccount.com] does not have permission to access projects instance [prj-b] (or it may not exist): Permission 'secretmanager.secrets.list' denied for resource 'projects/prj-b' (or it may not exist).
Is this by design?
If so cloudbuild is running in proj A, are there any methods to use the impersonated account in proj b to retrieve secrets deployed in proj B?
cheers
LinkedIn
Twitter
