A GCP service account key is a JSON file that lets a program authenticate as a service account in Google Cloud. Whoever holds the file does not need a password, a second factor or your network: they sign in as that service account from anywhere and get every IAM role it has been granted. That can mean storage buckets, databases, compute instances or the ability to create more credentials. Delete the key first, then work out what the service account could reach.
Check your GitHub account for leaked secrets — free
- Provider
- Google Cloud
- Severity
- Critical
- Impact
- Cloud infrastructure access
- Checked live by LeakWatch
- No
- Revoke at
- Google Cloud
What a GCP service account key looks like
The key is a small JSON document downloaded once, when the key is created. It contains the service account’s email, the project ID and a PEM private key stored as a single string with escaped line breaks:
{
"type": "service_account",
"project_id": "<project>",
"private_key_id": "…XXXX",
"private_key": "<PEM private key, masked>",
"client_email": "<name>@<project>.iam.gserviceaccount.com"
}
The private key is the secret. The email and project ID are identifiers: they tell an attacker where to point, but they do not grant access alone. The private_key_id is what you will match in the console to find the right key to delete.
Two things are not this secret. A Google API key (AIza…) is a different, much weaker credential: see the Google API key guide. A service account key is also different from the short-lived tokens Google issues to workloads running on its own infrastructure, which are never written to a file and cannot be committed.
How GCP service account keys get leaked
- The downloaded JSON file in the repository. The console offers the file once, and it often lands in the project folder next to the code, then gets committed with a broad
git add. - Application config. Key contents pasted into
.env, Terraform variables, Kubernetes secrets manifests or CI configuration files, usually as a single-line string. - Container images. A key copied into a Docker image with
COPYso the app can authenticate, and the image then published to a public registry. - Notebooks and tutorials. A Colab or Jupyter cell that loads the key inline, saved with its outputs.
- Shared archives and support threads. A zipped project or a log attached to a ticket, with the file still inside.
What to do in the first hour
- Find the service account and the key. In the Google Cloud console open IAM & Admin → Service Accounts, select the account named in
client_email, and open its Keys tab. Theprivate_key_idfrom the leaked file tells you which entry it is. - Create the replacement only if you must. If the workload runs on Google Cloud, prefer attaching the service account to the resource, or using Workload Identity Federation from outside, so no key file exists at all. If a key is unavoidable, create a new one and deploy it before step 3.
- Delete the exposed key. On the Keys tab delete it. Deleting ends the exposure; disabling the whole service account is an option if you cannot tell which keys were copied.
- Audit what it did. Open Logging → Logs Explorer and look at Cloud Audit Logs for the service account’s email, covering the period since the exposure. Admin Activity logs are on by default. Data Access logs often are not, so a quiet log is not proof that no data was read.
- Look for new credentials and resources. Check IAM for new members or roles, and the service account’s Keys tab for keys you did not create. Review compute instances, Cloud Run services, scheduled jobs and storage buckets you do not recognize.
Not sure what else leaked? Run a free scan. 6. Reduce its power. Open IAM and remove roles the service account does not need. Roles such as Owner or Editor on a service account turn one leaked file into a project-wide incident. 7. Prevent a repeat. Under IAM & Admin → Organization Policies, the constraint that disables service account key creation can be enforced for a project or organization. Then remove the file from the repository and rewrite history if you want to. See I accidentally pushed an API key to GitHub.
Revoke it at Google Cloud
Open console.cloud.google.com/iam-admin/serviceaccounts, choose the project the key belongs to (the project_id in the file), select the service account, and delete the key on its Keys tab. Keys belong to the project that owns the service account, so a key you cannot find is usually in another project. Once deleted, requests signed with it are rejected, although access tokens already issued from it may keep working for a short time, up to about an hour.
How LeakWatch detects it
The rule is called GCP Service Account. LeakWatch looks for the private_key field of a service account JSON file whose value is a PEM private key, with the line breaks written as escaped \n sequences as Google produces them. That is why a plain private key block in a .pem file is handled by a different rule. LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
I deleted the key. Is the service account safe?
The key is dead, but anything the attacker did while it was valid stays. Check for new keys, new IAM bindings and new resources, because those can persist after the original key is gone.
Can I find out who used the key?
Cloud Audit Logs record the service account’s email and often the caller’s IP address and user agent for each call. They show which API calls were made, but they cannot show data reads unless Data Access logging was enabled for that service.
Should I stop using service account keys altogether?
Where you can, yes. Attached service accounts and Workload Identity Federation remove the file, and an organization policy can block new keys. A key that never exists cannot be committed.