How to Store Sensitive Data on GCP: Secret Manager
Security is always recommended and is important in many applications. Our apps have some sensitive data such as passwords, IP addresses and credentials. How is this sensitive data stored? Are your techniques or tools safe? Also, when you have microservices where each has different databases or repositories, you could have a large amount of sensitive data or multiple microservices share repositories, how can this sensitive data be centralized?
Google Cloud Platform offers a service that allows you to centralize and securely save all this sensitive data. This service is Secret Manager, where you can store API keys, passwords, certificates, and other sensitive data that an application needs at runtime.
Some features are like this:
- Secret names are global project resources, but secret data is stored in regions, so it automatically handles the replication of secret data.
- Secret Manager is easy to integrate with your applications, code, and GitHub actions.
- Secret data is immutable, so you need to create a new version if you need to change the value.
- Encrypted in transit with TLS and at rest with AES-256-bit encryption keys.
- Cloud IAM integration.
- Access to secrets of other services and the hybrid environment with VPC.
- You can automate the rotation and expiration of secrets.
- Store, manage, and access secrets such as binary blobs or text strings.
Creating a Secret
Note: A secret is a global project object that contains a collection of metadata and secret versions.
Let’s start creating a secret. You can find this service in the security option like this:
Before, you need to enable the secret manager API, so that we can create a secret
When you create the secret, you can manually select the locations for the secret, or Google automatically manages it for you. Google recommends choosing the “automatic” replication unless you have specific location requirements.
Secret Manager secrets are always encrypted. By default, it uses a Google-managed key, but you can also configure Customer-Managed Encryption Keys (CMEK) to use your own keys.
Secret Manager supports rotation schedules about secrets. This feature is important to minimize risks or vulnerabilities. Secret Manager sends messages to Pub/Sub topics configured in the secret based on the provided rotation frequency and rotation time.
You can configure notifications for any action on the secret.
Finally, you could set an expiration date. The secret is automatically deleted once it expires.
Done, the secret is created
Managing Secrets
You can create new versions, enable, disable, or delete a secret easily.
Note: Secret versions are immutable.
You can create a new version like this:
Then you can enable or disable or remove some version of the secret.
You can also view the audit entries, who, when, and detailed information for each interaction. The registration information is like this:
About permissions, project Owners can access secrets, but other Google Cloud roles cannot access secrets (including the Editor role). Other users and service accounts must explicitly be granted permission to access the secret.
You can add an account with the appropriate role according to your need like this:
Creating and Accessing Secrets from Python
Secrets can be created using the SDK and your favorite programming language.
For example, Python looks like this:
The code is simple, it creates an instance of SecretManagerServiceClient, and with it, it is possible to create, delete, enable or disable a secret, also add new secret versions, retrieve secret versions, and more.
For example, retrieve the latest version of a secret:
For more examples with python visit my GitHub repository.
Using Secrets from Cloud Run
The secret manager can be used from various Google cloud services, for example, Cloud Build, Cloud Code (I have a video with this), Cloud Functions, Cloud Run, Compute Engine, and more, even from external services like GitHub Actions.
Cloud Run can use the secrets in three ways. First, create a dedicated service account. After that there are 3 ways to access secrets:
- Natively via envvars
- Natively via the filesystem
- Direct code integration
Bonus — Using Secrets from GitHub Actions
There is a GitHub Action created by Google ready for use. Prerequisite, the Google Cloud credentials that are authorized to access the secrets being requested
This is useful when you want Secret Manager to be the source of truth for your organization’s secrets, but you need to access those secrets in the build steps. Successfully obtained secrets are set as output variables and can be used in subsequent actions, something like this:
I hope this information is useful for you and I have a video with this. Remember to share this blog post, your comment is always welcome.
Visit my social networks:
