Let Google do Secret Management

Updated on August 15, 2022

In this post, I will talk about Google’s Secret Manager service and show how easy is to manage passwords/tokens in GCP.

Problem

Managing secrets and sharing secrets(like database passwords, tokens, etc..) is a hard problem and failing to secure tokens can lead to some serious issues.

An example scenario - When an application is being developed, it might need to connect to a database or need some certificates or need tokens(for example, Slack token) to make API calls. It is not a good practice to put these secret keys in the Source code as they live there forever and are visible to all people who have access to the source code. Sometimes, developers keep these keys in a separate local file (added to .gitignore) and share these keys using different methods like Slack chat, Email, etc… This approach is still not good as secret tokens are in plain text and scattered between team members. How do you manage a situation when a team member moves to a different team or different place? It is difficult to rotate keys and share them again with all the required team members.

You can read more about why secret keys should live separate than code at 12factor.net

Solution

The solution to this problem is Secret Management tools like Hashicorp Vault, Berglas, Google Secret Manager, AWS Secret Manager, etc. One of the popular tools out there is Hashicorp Vault but a team has to setup and manage their own infrastructure.

In this post, we will learn about Google managed secret management solution - Secret Manager, and see how easy is to store and retrieve keys and passwords.

What is Secret Manager?

Google Secret Manager is a recent addition to Google Cloud Platform which can store API Keys, passwords, certificates, sensitive strings, etc… You can read the Google Secret Manager’s release notes here and pricing here.

Google Secret Manager’s access control is integrated with Cloud IAM and a project owner can control who can read the secrets.

roles/secretmanager.admin : This role gives full access to administer the Secret. A person(or service account) with this role can perform CRUD(Create, Read, Update and Delete) operations on the Secrets.

roles/secretmanager.secretAccessor : This role provides access to read the Secret. A person(or service account) with this role can read the secret value store like API key.

roles/secretmanager.viewer: This role provides access to view the metadata of the Secret. A person(or service account) with this role can read the secret metadata but not the value stored.

Now that we are familiar with Google Secret Manager, let’s interact with this service.

Interacting with Secret Manager

Prerequisites

This post assumes the following:

1. We already have a GCP Project with the Project Owner role.
   
2. Google Cloud SDK (gcloud) is setup on your workstation. If you don’t have, then refer to my previous blogs - Getting started with Google Cloud SDK.
   

Note: You can also use Google Cloud Shell to run the gcloud commands.

Enabling the Secret API

To interact with Google Secret Manager, we need to enable this API.
Run the following command to enable this API.

$ gcloud services enable secretmanager.googleapis.com --project=workshop-demo-23345

Output

Operation "operations/acf.xxxxxxf-xxxx-xxxx-xxxx-xxxxxxx" finished successfully.

Create a Secret

Run the following gcloud command to create a secret.

gcloud secrets create demo-secret --replication-policy="automatic"

Output

Created secret [demo-secret].

Note:
1. This has created an empty secret that can hold multiple secret versions (actual sensitive information). 2. In this example, we used --replication-policy as automatic but can be user-managed to specify the location you want to put your secret in.

Add values to Secret

Secret Version contains the actual sensitive value.

echo "my_super_secret_string" | gcloud secrets versions add 'demo-secret' --data-file=-

Output

Created version [1] of the secret [demo-secret].

Adding another version or updating the secret value

echo "secret_update" | gcloud secrets versions add 'demo-secret' --data-file=-

Output

Created version [2] of the secret [demo-secret].

Read the Secret value

We can access the latest or specific secret version

Access the latest secret version

gcloud secrets versions access latest --secret='demo-secret'

Output

secret_update

Access specific secret version

gcloud secrets versions access 1 --secret='demo-secret'

Output

my_super_secret_string

Note: Never print the secret value in an application.

We can similarly, use the gcloud command or client libraries within the application to fetch the secret value when required instead of putting in source code or in some kind of property file.

Conclusion

Google Secret Manager enables developers to store and share the API Keys, passwords, etc in an easy fashion without having to manage tools like Vault, etc…

If you have feedback or questions, please reach out to me on LinkedIn or Twitter