Why does enabling the Cloud Run API create so many service accounts? Why do they have so many privileges?

Question

Enabling the Cloud Run API (dev console→Cloud Run→Enable) creates five service accounts. I want to understand their purpose. I need to know if it's my responsibility to configure them for least privileged access.

The Default compute service account has the Editor role. This is the Cloud Run runtime service account. Its purpose is clear, and I know it's my responsibility to configure it for least privileged access.

The App Engine default service account has the Editor role. This matches the description of the Cloud Functions runtime service account. Its purpose is unclear, given the existence of the Cloud Run runtime service account. I don't know if it's my responsibility to configure it for least privileged access.

The Google Container Registry Service Agent (Editor role) and Google Cloud Run Service Agent (Cloud Run Service Agent role) are both Google-managed service accounts "used to access the APIs of Google Cloud Platform services":

I'd like to see Google-managed service accounts configured for least privileged access. I'd also like to be able to filter the Google-managed service accounts in the IAM section of the GCP console. That said, I know I should ignore them.

The unnamed {project-number}{at}cloudbuild.gserviceaccount.com service account has the Cloud Build Service Account role. This service account "can perform builds" but does not appear in the Cloud Run Building Containers docs. It's used for Continuous Deployment—but can't do that without additional user configuration. It's not a Google-managed service account, but it does not appear in the Service Accounts section of the GCP console like the runtime service accounts. Its purpose is unclear. I don't know if it's my responsibility to configure it for least privileged access.

Answer 1

Cloud Run PM:

1. Yep, exactly right.
2. We should probably not create this if you're only using Run (and likely not enable the App Engine APIs, which is what created this). During Alpha, this was the runtime service account, and it's likely that it wasn't cleaned up.
3. I have a feeling it's stuck as Editor because it accesses Cloud Storage, which is oddly broken for "non Editor access" (I'm still trying to track down the exact issue, but it looks like there's a connection to the legacy Editor role that requires it).
4. Is already "least privileged" from it's perspective, as it only has the permissions to do the things that Run needs to do in order to set up resources on your behalf.
5. This is the runtime service account equivalent for Cloud Build, and falls into the same category as 1,2. If you need a build to deploy to Cloud Run, you have to grant this account something like Cloud Run Deployer (plus to the additional step of allowing the build service account to act as your runtime service account, to prevent [or at least acknowledge] privilege escalation).

I too want better filtering of "Google created" and "Google managed" and have been talking with the Cloud IAM team about this.