Cloud Functions broken by security fix for default Cloud Build SA

[eeaton]

Issue: Cloud Functions v2 relies on Cloud Build in the background to deploy AR resources, so it is silently impacted by the recent platform-wide security fix with the Cloud Build Service Account Change.

Many customers also use the org policy iam.automaticIamGrantsForDefaultServiceAccounts, which is a recommended security best practice, and also now enforced by default for all new customer orgs.

The combination of these two policies means that this terraform module will always fail. Deploying Cloud Functions depends on a Cloud Build job in the background, using the default compute SA, which must havepermissions like Storage Object Viewer to the the bucket gcf-v2-sources-$PROJECTNUMBER-$REGION. See example issue at https://github.com/terraform-google-modules/terraform-example-foundation/issues/1269

Recommend Fix:

• Document the dependency and troubleshooting guidance. (Either grant the roles that the legacy Build SA had to the default compute service account, or disable the org policy and continue to use the legacy Build SA with the caveat that this enables various privEsc paths)
• Expose a control for the user to specify which service account is used for the underlying cloud build job. (Not sure whether the Functions API itself already supports that, or if it would require an API-level fix

[eeaton]

Actually on further testing, the root cause might be an issue with the upstream Functions gen 2 API rather than the terraform modules.

Trying to deploy on console with both policies in place will consistently fail., with error messages like the following:

This function has failed to deploy and will not work correctly. Please edit and redeploy. Cloud Run service projects/$PROJECTID/locations/us-central1/services/function-1 for the function was not found. The function will not work correctly. Please redeploy. Build failed with status: FAILURE and message: failed to Fetch: failed to download archive gs://gcf-v2-sources-$NUMBER-us-central1/function-1/function-source.zip: Access to bucket gcf-v2-sources-$NUMBER-us-central1 denied. You must grant Storage Object Viewer permission to $NUMBER-compute@developer.gserviceaccount.com. . For more details see the logs at https://console.cloud.google.com/cloud-build/builds;region=us-central1/a5ed7bdf-db90-4578-97fe-1c54a713eb44?project=$NUMBER.

However, the fix remains the same either way: document the necessary permissions and allow the user to specify a user-managed service account used for the underlying build job

[prabhu34]

Fixed in #132

[eeaton]

@prabhu34 The fix unblocks the technical issue, but I think there's still a big challenge for usage and understanding.

Going forward, this module will fail by default for all new customers (the overlapping result of changes to default IAM grants to compute service account + changes to default Cloud Build service account. So an extra and non-intuitive step is required to make this work, even if the user thinks that the principal running the module has all the necessary permissions, one of:

1. add permissions to default compute SA
2. override org policies to use legacy behavior for cloud build SA
3. manually specify a build service account with sufficient privilege

I've suggested #133 , WDYT?