0

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 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?

Gridcell Coder
  • 693
  • 9
  • 18
  • have you (your user account) the permission to impersonate the service account X – guillaume blaquiere Jan 11 '23 at 21:03
  • @guillaumeblaquiere I can confirm that the user account has impersonation permissions and can access secrets in project A and project B. This was verified using gcloud impersonation commands. – Gridcell Coder Jan 12 '23 at 11:09

1 Answers1

0

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).
guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • If I `use the service account X from the project A as Cloud Build user managed service account.` I can only do this in Project A. The build pipeline is in Project B and in the console when I try and add a service account that is not in project B it comes up with the error `Failed to create trigger: generic::permission_denied: user does not have impersonation permission...` even though the console user can impersonate that account. Even through service X has access to project B resources and the cloud build service account from project B is in the iam section of project A, the error remains. – Gridcell Coder Jan 12 '23 at 11:20
  • "You can don this only in projectA" because you use the console! – guillaume blaquiere Jan 12 '23 at 11:56
  • Get the exact same error with Terraform and I have checked with gcloud and policy analyzer that I can impersonate the account X from account Y and my user account. Its still not clear who `user` is referring to. The console user, the Terraform user, the cloud build service agent, in console and terraform get the same 400 error code. – Gridcell Coder Jan 12 '23 at 12:30