Centralized secrets management addresses important DevOps security attack vectors such as secret sprawl and security islands, but it could help introduce a secret zero vulnerability if best practices aren’t followed. Secrets management eliminates the need for hardcoded secrets in source code and unmanaged extraneous secrets across your DevOps environment (secrets sprawl). In this article, we will discuss secret zero and best practices for reducing the risk.
The Secret Zero Problem
Secret zero is when all of your secrets are protected under another secrets, a single master key or ultimate secret that grants access to everything, the keys to the kingdom.
Improperly designed secrets management solutions have a master key that unlocks everything. For example, let’s say you have all your passwords stored in the cloud protected with a single password (P@$$W0rd1), and then you store the master password in a text file in cloud also, for your convenience. All a hacker needs to do is find or guess this one password to access everything. This master password is secret zero. It is a lot like putting all of your eggs in one basket or locking all of your keys in drawer and then putting that key in your pocket. The job is not done after securing your secrets, you also need to secure access to your secrets.
With this now large, single attack point, we are open to bad actors. Are we more open than when we didn’t have a secret manager? No, however, this is a lucrative vector within poorly designed secrets management solutions. Let’s talk about best practices for avoiding secret zero.
Secret Zero Solutions
Some solutions to secret zero split the master key or use hardware security modules (HSM) to provide authentication and authorization to the secrets manager. This, however, just moves the issue down a step. It helps, but not completely.
A better solution to secret zero is Conjur avoid the secret zero problem entirely by leveraging authenticators that work with the underlying infrastructure to authenticate access to your secrets.
In previous article we discussed Conjur’s approach to avoiding secret zero issues by saying it “avoids the secret zero problem by working with the underlying container orchestration systems running your applications to automatically authenticate machines requesting secrets with strong multi-factor authentication.” Conjur supports authentication in a number of orchestration systems such as Kubernetes and Cloud Foundry. Conjur’s unique security first architecture leverages these authenticators and others that we have created to provide secure authentication to our secrets manager that avoids the secret zero problem.
Authenticating Access to Your Secrets Vault
We will look at how this works in Kubernetes, as an example, allowing us to mitigate risk with better and safer authentication into our secret manager. Kubernetes authenticates its environment and the applications with Conjur in a number of ways before any secrets are released.
The first is a mutually-signed certificate that establishes the connection between Kubernetes and Conjur. You can see this in the “Verifying Conjur” section of the Kubernetes Authentication blog post. If the certificate is invalid or doesn’t exist, then the connection will fail. This is already stronger than one of the other solutions, split master keys. Having a system of mutually-signed certificates stored in the two environments avoids sharing keys across multiple environments and is individual to the system accessing the secret manager. This allows you to replace a single certificate without having to do this in every environment you may have. It also allows for more granular control of which environment has access to what keys, as you may have one cluster needing access to only particular secrets, not the master key to access all.
This leads to the second way to authenticate and authorize secrets: policy definition with greatly-improved granularity. As we just alluded to, having a separate certificate or connection to your secrets per environment allows for greater control of secret access when the connection is established. With Kubernetes, you can use extra controls to improve that access and decrease access to secrets where they are not needed. Using values like Namespace, Deployment, Stateful Set, Service Account, or Pod decreases the surface area of not just access to the secret vault but each secret you store within the manager. You can see this in Conjur’s documents.
Third, and finally, you can use a shared-access token. This is a rotating token the Conjur client and server use to allow applications within your Kubernetes cluster to retrieve secrets from your manager. You can see the documentation on how to set up and use the Conjur Kubernetes Authenticator on Conjur’s website.
Using the three steps above authenticates access to your secrets and avoids the secret zero problem. By authenticating access to secrets, you greatly reduce the attack area.
Next Steps
Moving and consolidating secrets management into a single secrets provider, rather than using multiple secret management services across multiple cloud service providers improves the security of your applications by avoiding security islands.
However, the next step after moving to a centralized secrets management solution is to address the secret zero problem. Leveraging Conjur authenticators helps you feel safe in the knowledge that a single key won’t grant attackers access to all of your applications by unlocking all of your secrets. With RBAC security policies you have the granularity of controlling what application and environments have access to what secrets. This restriction keeps your secrets safe and harder to compromise.
To discover for yourself how easy it is to tighten your application security, check out Conjur today.
John Walsh has served the realm as a lord security developer, product manager and open source community manager for more than 15 years, working on cybersecurity products such as Conjur, LDAP, Firewall, JAVA Cyptography, SSH, and PrivX. He has a wife, two kids, and a small patch of land in the greater Boston area, which makes him ineligible to take the black and join the Knight’s Watch, but he’s still an experienced cybersecurity professional and developer.