Secret Zero

Did you know that stolen credentials are the cause of two-thirds of data breaches in 2020 according to an investigation by Verizon? Secrets management is a job for not only cryptographers but also any DevOps or DevSec team.

Whenever employees need access to machines, databases, applications, services, servers, or any other sensitive resources, they need the right credentials to ensure secure access, hence the importance of secrets management. The system of secrets you use must be robust yet also easy enough to use that it doesn’t cause friction in your workflow.

Most businesses use technologies like Vaults and hardware security modules, but we need to talk about a dilemma in corporate cybersecurity known as the “secret zero.”

What Is the Secret Zero?

Enterprise-grade digital security starts with secrets, or the passwords, tokens, keys, and credentials used to grant sanctioned access to sensitive company data. You start off with a large number of secrets, so you adopt a central Vault to store them.

However, a DevOps Vault itself needs secrets so that access to it is secure. At some point, you need a single, final secret at the end (or beginning) of this chain. This credential is known as “secret zero.” How do you manage such a critical point in your organization?

Tackling the Secret Zero Problem

Businesses operating in private cloud environments that are hosted on-premises need their own method of protecting secret zero. Some common methods are machine authentication using API keys and a machine parameter, such as an IP address. However, these solutions are not perfect. Vulnerabilities include the potential for stolen API keys and IP spoofing attacks.

If you work with cloud providers, then you can eliminate secret zero by outsourcing the job to your third-party. Many services from AWS to Azure have their own mechanisms for managing secrets, but the walled garden issue comes up if trying to use multiple tools or clouds.

Comparison of Secret Zero Solutions

Every solution vendor has its own way of solving the secret zero dilemma. Some companies split access to the master key so that one compromised location doesn’t expose the entire network. Others use tools like hardware security modules for authorization. However, these solutions merely move the issue somewhere else rather than completely solve it.

Some examples of secrets management solutions that specifically target secret zero dilemmas are HashiCorp, Conjur, and Akeyless.

Akeyless

Akeyless removes the need for secret zero entirely through its Akeyless Universal Identity feature, packaged within the Akeyless Vaultless Platform. In this setup, every machine can identify other machines in the network to ensure the data received is authentic. Akeyless uses its own plugin to allow the Vault and environment to interact in a secure fashion.

The process begins with a starter token created by a human employee that’s used once to authenticate the plugin. From there, Akeyless issues its own tokens and begins authenticating applications. That token is replaced by a new one in the next use for a specified amount of time.

Whenever a new entity is registered under this system, it inherits the identity and token of the original entity. This constant cycle of temporary, rotating identity tokens is a secure alternative to using a single secret zero.

HashiCorp

HashiCorp Vault offers a Response Wrapping feature uses a system of wrapped tokens. When an application receives a wrapped token, it unwraps it to retrieve the correct secret to gain access.

Since a token can only be unwrapped once, an alert comes up whenever an application is unable to unwrap a token. This incident is a sign that the token has already been unwrapped somewhere else and can therefore be considered stolen.

Conjur

In Conjur’s own words, the platform works by “leveraging authenticators that work with the underlying infrastructure.” Conjur focuses on authenticating access to secrets and reducing the potential attack area of a business. It works in three main ways:

• Integration with Kubernetes. Using a mutually-signed certificate between Kubernetes and Conjur, the platform signs the certificate in both environments and cuts off the connection between them if the certificate is invalid. The secret does not have to be shared between the two.
• Policy Definitions. Conjur gives more granular control over what environments have access to what keys. This way, there is no need to give the master key to everyone. Kubernetes secrets can be adjusted to minimize the incidence of Vault access.
• Shared-Access Tokens. Finally, Conjur uses rotating tokens so that applications can retrieve secrets from the manager securely. The site has its own documentation of this feature.

A combination of these features constitutes Conjur’s approach to secret zero.