In a recent blog post, Google announced Secret Manager, a new service in beta for managing credentials, API keys, and certificates when using Google Cloud Platform. The intent of this service is to reduce secret sprawl within an organization’s cloud deployment, and instead ensure that there is a single source of truth for managing credentials. Features of the service include global replication, versioning, audit logging, strong encryption, and support for hybrid environments.
This service was created due to customer feedback that managing secrets regionally created a lot of friction. Seth Vargo, a google cloud developer advocate, explains:
Early customer feedback identified that regionalization is often a pain point in existing secrets management tools, even though credentials like API keys or certificates rarely differ across cloud regions. For this reason, secret names are global within their project.
Secret names have a global scope, but the data remains regional. This allows for transparency across the enterprise while keeping the data in a local region. However, administrators can choose which regions secrets can be replicated to.
Secret Manager has been built with "principle of least privilege", and accordingly only project owners have access to secrets, unless explicit Cloud IAM permissions have been provided. All secret information is encrypted in transit with TLS and at rest, using AES-256 encryption.
Versioning is another capability that is included in Secret Manager. For example, an organization may need to support a gradual rollout of a version of their app or the need to rollback. Versioning is automatically provided for operations including access, destroy, disable and enable.
As organiazations focus on being agile, there is a need for an application to always be using the latest version of a secret. To support this requirement, there is an alias called 'latest' that will always return the latest version of the secret. Vargo explains why this is an important feature:
Production deployments should always be pinned to a specific secret version. Updating a secret should be treated in the same way as deploying a new version of the application. Rapid iteration environments like development and staging, on the other hand, can use Secret Manager's latest alias, which always returns the most recent version of the secret.
Creating and accessing secrets can be accomplished through the Secret Manager API, Secret Manager Client Libraries and Cloud SDK. For example, the following command can be used to create a secret:
$ gcloud beta secrets create "my-secret" --replication-policy "automatic" --data-file "/tmp/my-secret.txt"
Discovering where secrets are being used within your cloud deployment can often times be difficult. Organizations can discover secrets in Cloud DLP using infoType detectors to identify where entities such as AUTH_TOKEN, BASIC_AUTH_HEADER and ENCRYPTION_KEY are being used.
Some organizations have previously used Berglas, an open source tool, for managing secrets in Google Cloud Platform. Customers can continue to manage secrets using this tool or can use the ‘migrate’ command from a Berglas command line to provide a one-time migration of the secret to Secret Manager.
Secret Manager beta is available to all Google Cloud customers and Quickstart tutorials have been published.