Service account keys are private keys that let you authenticate as a service account. Key rotation is the process of replacing your existing keys with new keys and then invalidating the replaced keys. We recommend that you routinely rotate all keys that you manage, including your service account keys.
Rotating service account keys can help reduce the risk posed by leaked or stolen keys. If a key is leaked, it might take bad actors days or weeks to discover the key. If you regularly rotate your service account keys, there's a higher chance that the leaked keys will be invalid by the time a bad actor gets them.
Having an established process for rotating service account keys also helps you act quickly if you suspect that a service account key has been compromised.
How often to rotate keys
We recommend rotating your keys at least every 90 days to reduce the risk posed by leaked keys.
If you believe that a service account key has been compromised, we recommend that you rotate it immediately.
Key rotation process
To rotate service account keys, do the following:
- Identify the service account keys that need to be rotated.
- Create new keys for the same service accounts.
- Replace the existing keys with the new keys across all applications.
- Disable the replaced keys and monitor the applications to confirm that they work as expected.
- Delete the service account keys that were replaced.
You can complete these steps by using a centralized secret management service, or by using a custom notification system.
Centralized secret management service
Many centralized secret management services, like HashiCorp Vault, provide automatic secret rotation. You can use these services to store and rotate your service account keys.
We don't recommend using Google Cloud's Secret Manager to store and rotate service account keys. This is because, to access Secret Manager secrets, your application needs an identity that Google Cloud can recognize. If your application already has an identity that Google Cloud can recognize, then your application can use that identity to authenticate to Google Cloud instead of using a service account key.
The same concept applies for other cloud-based secret management services, like Azure KeyVault and AWS Secret Manager. If an application already has an identity that these cloud providers can recognize, your application would be able to use that identity to authenticate to Google Cloud instead of using a service account key.
Custom notification system
Another approach to service account key rotation is to create a system that sends notifications when keys need to be rotated. For example, you could create a system that sends alerts when it detects keys that were created more than 90 days ago.
First, you need to identify the keys that need to be rotated. To identify these keys, we recommend using Cloud Asset Inventory to search for all service account keys that were created before a certain time.
For example, the following command lists all service account keys that were
created before 2023-03-10 00:00:00 UTC in the organization with the ID
123456789012:
gcloud asset search-all-resources \
--scope="organizations/123456789012" \
--query="createTime < 2023-03-10" \
--asset-types="iam.googleapis.com/ServiceAccountKey" \
--order-by="createTime"
To learn more about searching resources in Cloud Asset Inventory, see Searching resources. After identifying the keys that need to be rotated, you can send out notifications to the appropriate teams.
When someone is notified to rotate a key, they should do the following:
- Create a new key for the same service account.
- Replace the existing key with the new key across all applications.
- Disable the key that they replaced and monitor the applications to confirm that they work as expected.
- After they confirm that the applications are working as expected, delete the replaced key.
Expiring service account keys
We don't recommend using expiring service account keys for key rotation. This is because expiring keys can cause outages if they aren't rotated properly. For more information about the use cases for expiring service account keys, see expiry times for user-managed keys.