Google Cloud Platform
Help keep your Google Cloud service account keys safe: taking charge of your security
Google Cloud Platform (GCP) offers robust service account key management capabilities to help ensure that only authorized and properly authenticated entities can access resources running on GCP.
If an application runs entirely on GCP, managing service account keys is easy — they never leave GCP, and GCP performs tasks like key rotation automatically. But many applications run on multiple environments — local developer laptops, on-premises databases and even environments running in other public clouds. In that case, keeping keys safe can be tricky.
Ensuring that account keys aren’t exposed as they move across multiple environments is paramount to maintaining application security. Read on to learn about best practices you can follow when managing keys in a given application environment.
Introducing the service accountWhen using an application to access Cloud Platform APIs, we recommend you use a service account, an identity whose credentials your application code can use to access other GCP services. You can access a service account from code running on GCP, in your on-premises environment or even another cloud.
If you’re running your code on GCP, setting up a service account is simple. In this example, we’ll use Google Compute Engine as the target compute environment.
- Create a service account
- Grant least-privilege permissions to the service account using IAM. For example, if your application only needs to access Google Cloud Storage, then grant the service account the roles/storage.admin role.
- Next, install the client library for the language in which your application is written. (You can also use the SDK but the client libraries are the most straightforward and recommended approach.) With this, your application can use the service account credentials to authenticate applications running on the instance. You don’t need to download any keys because you are using a Compute Engine instance, and we automatically create and rotate the keys.
Protecting service account keys outside GCPIf your application is running outside GCP, follow the steps outlined above, but install the client library on the destination virtual or physical machine. When creating the service account, make sure that you're following the principles of least-privilege. This is good practice in all cases, but it becomes even more important when you download credentials, as GCP no longer manages the key, increasing the risk of it being inadvertently exposed.
In addition, you’ll need to create a new key pair for the service account, and download the private key (which is not retained by Google). Note that with external keys, you're responsible for security of the private key and other management operations such as key rotation.
Applications need to be able to use external keys to be authorized to call Google Cloud APIs. Using the Google API client libraries facilitates this. Google API client libraries use Application Default Credentials for a simple way to get authorization credentials when they're called. When using an application outside of GCP, you can authenticate using the service account for which the key was generated by pointing the GOOGLE_APPLICATION_CREDENTIALS environment variable to the location where you downloaded the key.
Best practices when downloading service account keysNow you have a key that can gain access to GCP resources, you need to ensure that you manage the key appropriately. The remainder of this post focuses on best practices to avoid exposing keys outside of their intended scope of use. Here are best practices to follow:
- If you’ve downloaded the key for local development, make sure it's not granted access to production resources.
- Rotate keys using the following IAM Service Account API methods:
- Replace old key with new key
Key rotationKeyrotator is a simple CLI tool written in Python that you can use as is, or as the basis for a service account rotation process. Run it as a cron job on an admin instance, say, at midnight, and write the new key to Cloud Storage for developers to download in the morning.
It's essential to control access to the Cloud Storage bucket that contains the keys. Here’s how:
- Create a dedicated project setup for shared resources.
- Create a bucket in the dedicated project; do NOT make it publicly accessible.
- Create a group for the developers who need to download the new daily key.
- Grant read access to the bucket using Cloud IAM by granting the storage.objectViewer role to your developer group for the project with the storage bucket.
Prevent committing keys to external source code repositories
You should not need to keep any keys with your code, but accidents happen and keys may inadvertently get pushed out with your code.
One way to avoid this is not to use external repositories and put processes in place to prevent their use. GCP provides private git repositories for this use case.
You can also put in place preventive measures to stop keys from being committed to your git repo. One open-source tool you can use is git-secrets. This is configured as a git hook when installed
It runs automatically when you run the
‘git commit’ command.
You need to configure git-secrets to check for patterns that match service account keys. This is fairly straightforward to configure:
Here's a service account private key when downloaded as a JSON file:
"private_key": "-----BEGIN PRIVATE KEY-----\thisiswhereyourprivatekeyis\n-----END PRIVATE KEY-----\n",
To locate any service account keys, look for patterns that match the key name such as ‘private_key_id’ and ‘private_key’. Then, to locate any service account files in the local git folder, add the following registered patterns:
git secrets --add 'private_key'
git secrets --add 'private_key_id'
Now, when you try to run ‘git commit’ and it detects the pattern, you'll receive an error message and be unable to do the commit unless mitigating action is taken.