‘Secrets’, in the context of cybersecurity and DevSecOps, describes the digital authentication credentials used in applications and services; anything you don’t want to share. The secrets you need to keep safe may include:
These secrets need to stay secret because they are the doors to your data—if the wrong person gets hold of them, you have the potential to have an unwelcome intruder in your systems wreaking whatever havoc they can. Applications leak secrets under all sorts of circumstances: applications frequently log configurations, leaving them in log files or centralized logging systems. Often secrets will be captured in exception tracebacks or crash reports sent to external monitoring systems, or they will be leaked via debugging endpoints and diagnostic pages after hitting an error. Here are some examples of what can happen when secrets aren’t properly kept:
So, are you sure your secrets are safe? Can you answer these questions?
You might now be thinking that it used to be easier to answer those questions. Historically the IP address was the unit of identity for security, and independent from any PKI identity. This was a workable approach when IPs were relatively static, and the rate of change was low. The challenge we are facing in the DevOps world is that our secrets are proliferating as a result of our desire to deploy changes more frequently. Our use of cloud and other modern technology practices (e.g. microservices, containers) makes our infrastructure more dynamic and ephemeral. We can’t use the IP address now because it’s no longer a static value from which we can base all our policies. It’s really hard for the technology teams to keep up even with the basic tasks of secrets generation, rotation, revocation, assignment, and sharing, particularly with all the other pressures on us to digitally transform, move from project to product, automate and evolve our cultures.
Causes of Proliferation
Bad Behaviour: Secrets Sprawl
Secrets sprawl describes the surface area on which an organization’s secrets are stored along with the sheer volume of secrets as well as issues with secrets being duplicated and residing in multiple places—they have sprawled from their original and safe home. It is by no means uncommon for secrets to be stored in plain text in a variety of different places such as:
Best Practices for Secrets Management in DevSecOps
The best current way to ensure you and your teams are following these best practices is to use a Secrets Management tool for centralization. This kind of tool puts your secrets in a secret place, wraps that with encryption and access control, and provides fine-grained audit logging so you know who's doing what, when and only give access to people and applications that need it.
You should also encourage your teams to continuously reference the twelve-factor pattern to reduce application dependencies on credentials from external services. You can also consider using dynamic secrets: a dynamic secret is generated on demand and is unique to a client, instead of a static secret, which is defined ahead of time and shared. Dynamic secrets help reduce the blast damage of any leaked secrets or compromised systems because every authenticated entity will have a unique set of credentials.
Your secrets hierarchy design should account for secrets isolation per application, environment and a fail-proof revocation of secrets when required. To further strengthen the secrets structure, access policies and role-based mappings need to be built to support emergencies by making them version-controlled and automated.
It’s important that a secrets management tool has comprehensive and accessible APIs and integrations to other security tools such as machine identity protection tools like those offered by Venafi. The Venafi and HashiCorp Vault integration allows DevOps teams to obtain TLS keys and digital certificates using the Machine Identity Protection service operated by the organization’s security team: that’s DevSecOps in action.
Find out more about how Venafi and HashiCorp together make it faster and safer for DevOps teams to generate external certificates for their applications here and provide much needed policy controls and visibility for security teams.