Service accounts should use only Google-managed keys

A downloaded service account key is a file that works from anywhere until it is deleted. It can be copied into a repository, a ticket or a laptop backup and used by anyone who finds it, with no MFA and often no expiry. Google's guidance is to avoid user-managed keys where possible and to use attached service accounts or workload identity federation instead, because those hand out short-lived credentials that never exist as files.

Sources: Google Cloud: best practices for managing service account keys, Google Cloud: list service account keys.

In the Google Cloud console open IAM & Admin → Service Accounts, select an account and open the Keys tab. Keys with the type User managed are the ones this check is about.

With gcloud, this read-only command lists only the user-managed keys of one service account. An empty list is the safe result:

gcloud iam service-accounts keys list \
  --iam-account=my-sa@my-project.iam.gserviceaccount.com \
  --managed-by=user

Loop over the output of gcloud iam service-accounts list --project=my-project to cover a whole project, and repeat per project.

For each key, find what uses it. Move that workload to an attached service account (on Compute Engine, Cloud Run or GKE) or to workload identity federation if it runs outside Google Cloud. Once the workload runs without the key, disable it in the Keys tab or delete it:

gcloud iam service-accounts keys disable KEY_ID \
  --iam-account=my-sa@my-project.iam.gserviceaccount.com

Disable first, watch for failures, then run keys delete with the same arguments. To stop new keys appearing, an administrator can enable the organization policy that blocks service account key creation, described in the Google Cloud organization policy documentation. ConfigCobra itself never changes your projects. It reports the finding and gives you the steps.

Any application, build job or script that still signs in with a downloaded key fails with an authentication error as soon as the key is disabled or deleted. This is the main risk, which is why disabling first gives you a way back. Workloads that run on Google Cloud with an attached service account are not affected. If you enable the organization policy that blocks key creation, developers can no longer create keys on their own, so they need to know the approved alternative first. Third-party tools that insist on a key file may need an exception on a specific project.