Improving your security posture with centralized secrets management

Adopting centralized secrets management is an important step in improving your organization's security posture. Centralized solutions provide unified auditing, access controls, and policy management, but many organizations struggle to install, configure, and drive internal adoption of these solutions due to lack of integrations, lack of experience, or organizational resistance.

One of the biggest advantages of a centralized secrets management solution is mitigating secret sprawl. Without a centralized solution, secrets–like API keys, certificates, and database passwords–often end up committed to a source repository, saved on a corporate wiki page, or even written on a piece of paper. When secrets are sprawled like this, you lose the ability to easily audit and control access to their values, allowing an attacker to move undetected throughout a system, as has happened in several recent data breaches.

Secret Manager is a generally available (GA) centralized secrets management solution hosted on Google Cloud. With Secret Manager, you don't have to install custom software or manage any systems, and you can easily store credentials and other sensitive data, manage permissions using Cloud IAM, and audit access using Cloud Audit Logs. And since Secret Manager is a fully-managed service, running it doesn’t create extra operational overhead.

Adopting a centralized secrets management solution is not without challenges, however. Many customers operate in heterogeneous environments and platforms, meaning secrets need to be accessed from varying software stacks, programming languages, operating systems, and third-party services. For example, what if a CI/CD system needs an API token, or an automation tool needs to store a TLS certificate. Without integrations between these systems, developers will most likely copy-and-paste their secrets into third-party systems, circumventing the overall value of centralization. A good secrets management solution, then, needs to provide extensibility and interoperability with first- and third-party systems.

While Secret Manager already integrates with Google Cloud products like Cloud IAM and VPC Service Controls, we recognize many of our customers use tools and technologies outside of our cloud ecosystem. This post looks at some popular third-party tools and services, and shows you how Secret Manager can help create, manage, and access secrets in those systems.

HashiCorp Terraform

HashiCorp's Terraform is a popular third-party tool for provisioning and managing Infrastructure as Code. You can create, manage, and access secrets from within their existing infrastructure templates.

Suppose your infrastructure setup includes generating a TLS certificate. You can generate that certificate using Terraform and then store the corresponding private key in Secret Manager:

If you already have a Secret Manager secret, you can access it from Terraform:

In addition to creating and accessing secrets, you can also enable, disable, and destroy secret versions, as well as manage Cloud IAM permissions. For more information, check out the Terraform Google Secret Manager documentation.

GitHub Actions

GitHub Actions is a popular CI/CD solution integrated into GitHub. You can access Secret Manager secrets from your GitHub Action build steps and export those secrets for use in subsequent build steps.

While you could store secrets directly on GitHub, over time this will lead to secret sprawl and reduced auditability. Decentralized secrets management increases the challenge of auditing and controlling access. For this reason, we developed a GitHub Action so you can use Secret Manager as your centralized secrets management solution.

Suppose your GitHub Action needs to publish a container image to a private registry, which requires an API token. You would create and store this API token in Secret Manager and then configure your GitHub Action to pull this value from Secret Manager as-needed.

This ensures that each execution of your GitHub Action generates an audit entry, and you can revoke access to the secret at any time using Cloud IAM.

Spring Boot

The Spring Cloud GCP project allows Spring Boot developers to adopt and integrate with Google Cloud services in their microservices. Since Spring Cloud GCP 1.2.3, you can access Secret Manager secrets as Spring configuration values. This provides a convenient and familiar abstraction for Java developers and improves portability across various environments like development, staging, and production.

With Spring Cloud GCP, you can access one or more properties in your application.properties file:

Alternatively, you can map secrets directly inline, without needing to store them in an intermediate property value:

That's it! The Spring Cloud GCP project handles all the heavy lifting. You can see the complete sample on GitHub.

Berglas

Berglas is a predecessor to Secret Manager, but it’s now fully interoperable with Secret Manager. That means you can create, manage, and access Secret Manager secrets using the familiar Berglas APIs. Whereas previously you would use the berglas:// prefix to specify a secret, you can now use the sm:// prefix to refer to a Secret Manager secret.

As an added bonus, existing Berglas users can migrate to Secret Manager using the berglas migrate command.

Integrations ahead

Adopting a tool like Secret Manager improves your security posture with centralized auditing and access controls, so you can easily manage, audit, and access secrets like API keys and credentials. With these new integrations, you can now accomplish these tasks from your favorite tools, frameworks, and services—all with minimal changes to your existing workflows.

At Google Cloud, we aim to make security as easy as possible. We look forward to sharing more first- and third-party integrations, better encryption controls, and expanded management functionality with you in the future.

Finally, we would love your feedback! Please connect with us via any of the Secret Manager forums and ask questions on our Stackoverflow tag.