How to remove user-managed service account keys in Google Cloud

A user-managed key is a downloadable credential file for a service account. If it leaks, whoever holds it can act as that account until the key is deleted.

• Roles to look: Service Account Viewer (roles/iam.serviceAccountViewer) to list accounts and keys, and Activity Analysis Viewer (roles/policyanalyzer.activityAnalysisViewer) to see key last-use times.
• Roles to change: Service Account Key Admin (roles/iam.serviceAccountKeyAdmin) on the project or the service account, and Organization Policy Administrator (roles/orgpolicy.policyAdmin) for the organisation policy.
• Tools: the Google Cloud console or the gcloud CLI, with the IAM and Policy Analyzer APIs enabled.
• Know the replacements: attach a service account to the Compute Engine VM or other resource that runs the workload, use workload identity federation for workloads outside Google Cloud, or impersonate the service account with --impersonate-service-account. These all use short-lived tokens.

Steps 1 and 2 only read information. Steps 3 to 6 change your environment and are marked CHANGE. Work one project at a time.

1. List user-managed keys (read-only). Console: IAM & Admin > Service Accounts, open an account and check the Keys tab. To cover a whole project:

   for sa in $(gcloud iam service-accounts list --project=PROJECT_ID --format='value(email)'); do
     echo "== $sa"
     gcloud iam service-accounts keys list --iam-account="$sa" --managed-by=user --project=PROJECT_ID
   done

   Keys that Google manages itself are excluded by --managed-by=user. Note each key ID and its owner.
2. Check when each key was last used (read-only).

   gcloud policy-intelligence query-activity --activity-type=serviceAccountKeyLastAuthentication --project=PROJECT_ID

   This feature is in preview. A key that does not appear has no recorded use in the observation period, but recent use may be missing and use outside Google Cloud, such as domain-wide delegation, is not tracked. Cross-check with Cloud Monitoring service account usage metrics before you remove anything.
3. CHANGE: move the workload to short-lived credentials. For each key still in use, switch its application to an attached service account, workload identity federation or impersonation, and deploy that change first.
4. CHANGE: disable the key, then wait. Disabling is reversible, so use it as a trial run:

   gcloud iam service-accounts keys disable KEY_ID --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com --project=PROJECT_ID

   Watch for failures for a period that fits your batch jobs, for example a full month-end cycle. If something breaks, re-enable it with the same command using keys enable.
5. CHANGE: delete the key. Google states a deleted key cannot be undeleted:

   gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

6. CHANGE: stop new keys being created. Enforce the organisation policy constraint for your organisation:

   gcloud resource-manager org-policies enable-enforce --organization ORGANIZATION_ID iam.disableServiceAccountKeyCreation

   The constraint is not retroactive, so existing keys keep working until you remove them. Creating a key afterwards fails with "Key creation is not allowed on this service account". For organisations created on or after 3 May 2024 this constraint is enforced by default. If one project genuinely needs keys, grant an exception at that project rather than switching the policy off.

These commands only read.

gcloud iam service-accounts keys list --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com --managed-by=user --project=PROJECT_ID
gcloud resource-manager org-policies describe iam.disableServiceAccountKeyCreation --effective --project=PROJECT_ID

The first command should list no keys for accounts you cleaned up. The second should show the constraint as enforced for the project. Repeat the loop from step 1 for every project in scope and confirm the output is empty.

• Deleting a key straight away instead of disabling it first, then finding a quarterly job depended on it.
• Trusting last-use data alone. It is preview data and does not cover every kind of use.
• Assuming that disabling a key revokes short-lived tokens already issued from it. To revoke those, disable or delete the service account.
• Expecting the organisation policy to remove existing keys. It only blocks new ones.
• Setting key expiry before key creation is blocked, which can cause outages from forgotten permanent keys.
• Cleaning one project and forgetting the rest of the organisation.

ConfigCobra is read-only: it never changes your Google Cloud. It uses a read-only service account with viewer-level roles, covering every project in the organisation or a selected list, and checks against the CIS Google Cloud Platform Foundation Benchmark v5.0.0 (93 controls). The related checks below cover user-managed keys, their rotation and broad service account roles.

The Google Cloud inventory lists resources across the projects in scope. Remediation impact analysis shows the affected resources and identities before you apply a fix, and scheduled scans with drift detection send an email when a control regresses, for example when a new key appears.