candccoder
candccoder

Reputation: 803

Cross project service account impersonation for cloud build

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/[email protected]
  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 e.g 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?

Upvotes: 1

Views: 1170

Answers (1)

guillaume blaquiere
guillaume blaquiere

Reputation: 75970

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).

Upvotes: 1

Related Questions