用于云构建的跨项目服务帐户模拟

Question

We have a use case where project A has some secrets and databases which cannot be moved to another project. We have a project B that uses the secrets and databases from project A .

Project A has a service account X that accesses the secrets and databases.

Project B has a service account Y with no permissions to the secrets and databases. The goal is for service account Y to impersonate service account X during a build trigger connected to pushes to github. Project B has a cloud build pipeline that needs to temporarily access the secrets and database in Project A during the CICD process.

According to this:https://cloud.google.com/build/docs/cloud-build-service-account , section User-specified service account...You can create a custom IAM role with an impersonation permission or use pre-defined roles that allow principals to impersonate a service account.

I create a service account X and gave service account Y permissions to impersonate it (as checked in policy analyzer) however, when I try to use service account X in project B 's cloud run trigger I get (as expected):

Failed to update trigger: generic::permission_denied: user does not have impersonation permission on the trigger service account specified: projects/redacted/serviceAccounts/service@project-A.com

1. What "user" is this referring to? The one using the console? the build service agent?

2. Is it possible to get a service account Y in Project B to impersonate service account X in Project A during the build step process?

According to this https://cloud.google.com/build/docs/securing-builds/configure-user-specified-service-accounts ... To use the Triggers page in the Google Cloud console, the user-specified service account and the build trigger must be in the same project.

Is there a workaround for this eg is it necessary to use gcloud to impersonate the account? Or is there a way to perform cross project account impersonation (for triggers) using the cloudbuild.yaml or somehow tell the trigger that the service account being used must impersonate another?

Answer 1

you have 2 solutions:

• Use the service account X from the project A as Cloud Build user managed service account. You have to grant the Cloud Build Service Agent service account the permission to impersonate the service account X in project A. In addition, this service account X must have access to your project B resource also to interact with them. This solution is convenient because you can use the built-in connection with secret manager
• Use the current configuration, but perform manual impersonation in the Cloud Build pipeline when you want to get the secrets (with code, not with the Cloud Build built-in integration with secret manager).