GCP – Automatically disabling leaked service account keys: What you need to know

At Google, we’re always evolving our security capabilities and practices to make our cloud the most trusted cloud. As part of this continued effort, Google Cloud’s Identity and Access Management (IAM) recently released even stronger security defaults that can help you bolster the baseline security and control of your cloud environment. 

We offer several options when you need to allow external applications to access Google Cloud APIs and resources including guidance on how to choose a more secure alternative to service account keys. However, many organizations still depend on service account keys for external authentication, which can create security issues if those keys are inadvertently disclosed.

Today, we are enhancing our detection service that regularly scans public repositories for leaked keys and notifies customers if they are found. Starting June 16, 2024, exposed service account keys that have been detected in services including public repos will be automatically disabled by default for new and existing customers. Customers can opt in to this enhanced service in advance of June 16, and we also provide the option to opt out for customers who wish to continue with the current (less-secure) behavior when leaked keys are detected. 

Disabling leaked service account keys is an organization policy update. It is made possible by working in close partnership with secret-scanning programs at public repositories including Github and Gitlab. For example, Google Cloud might detect a particular service account key has been exposed in a public repository and you can rely on this new capability to automatically disable the leaked key. 

We notify all project owners and listed security contacts when leaked keys have been detected and when keys are automatically disabled. It’s critical to keep your security contacts updated so that you can get these security notifications in a timely manner.

Safeguarding your cloud environment with enhanced protection

At many organizations, private service account keys have elevated permissions both at the project and folder levels. These keys can easily be mishandled due to human error, leading to leaked keys in internal logs, emails, and public repositories. 

In scenarios where these keys get exposed in public repositories and services, bad actors automatically scan for leaked keys so they can quickly abuse them.  Malicious actors will use stolen keys in crypto mining operations or sell them to others for hacking campaigns.

Despite these risks, we understand many of our customers use service account keys in production environments and that automatically disabling leaked keys might impact production workflows. To ensure a smooth transition for your production environments, we are giving our customers the option to opt in or opt out of this protection until June 16. 

After June 16, disabling leaked key protection will be turned on by default for existing customers who didn’t make a selection, to help safeguard their cloud environments. We strongly recommend you opt in earlier for the added security and peace of mind that extra protection against leaked key abuse can provide, though you should carefully weigh the potential impact to your production environment and opt-out if needed based on your business requirements. 

If your organization is required to opt out for now, we encourage you to regularly analyze your situation and make necessary changes to your environment so that you can take advantage of this secure-by-default capability. 

While this feature gives you an additional  layer of security for your cloud environment, it’s still vital for your organization to design and implement security best-practices that can safeguard the keys to your cloud estate. For example, you should avoid embedding keys in code to minimize exposure risks, perform frequent key rotations, and enforce strong IAM policies based on the principle of least privilege. 

Our commitment to protecting your Google Cloud environment is unwavering and this proactive measure against exposed service account keys reflects our shared fate model — helping you protect your cloud environment from security threats.

3 steps to automatically disable exposed service account keys 

For Google Cloud customers who are ready to automatically disable exposed service account keys today, follow these three steps. 

Step 1: Organization administrators should go to the Organization Policies page in the console and find the constraint with the ID “constraints/iam.serviceAccountKeyExposureResponse”.

Step 2: Click on “Manage Policy” to set the policy source to “Override parent’s policy” and select “Replace” for policy enforcement.

Step 3: You have the following opt-in or opt-out options to automatically disable exposed service account keys. You can add a custom allow rule with one of the following values:

DISABLE_KEY: If Google Cloud detects an exposed key, it will automatically disable the key. It also sends a notification about the exposed key to project owners and security contacts.

WAIT_FOR_ABUSE: Google Cloud won’t proactively disable exposed keys. However, Google Cloud might still disable exposed keys if they’re used in ways that adversely affect Google Cloud . Regardless of whether the exposed key is disabled, Google Cloud sends an email notification about the exposed key to project owners and security contacts.

Note: By default, if an organization (new or existing) does not select WAIT_FOR_ABUSE this capability automatically uses the DISABLE_KEY option starting June 16.

Once this is configured, all newly detected leaked service account keys under the organization, folder, and project will automatically be disabled.

For more information

You can read more about automatically disabling leaked service account keys in our public documentation for service account key exposure response. To learn more about service accounts, you can watch this video primer and refer to our Service Accounts overview guide.