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, 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
.
What's next