How to Eliminate Secret Zero and Stop Nesting Secrets

One of the biggest challenges organizations face is how to securely authenticate client requests for services and to securely distribute secrets without a secret zero. Many secrets management solutions rely upon a master key or secret zero to protect the crown jewels. Secret zero is an irresistible target for attackers, so it is typically stored in a Hardware Security Module (HSM), which itself requires credentials to access it, and those credentials must be stored securely too — you get the idea. This scenario is often compared to Russian nesting dolls, where opening one doll reveals many smaller dolls. This only gives you the illusion of security as you exchange one vulnerability for a different one.

Some secrets management solutions claim to solve the secret zero problems by splitting the master credentials in two by requiring both a role identifier and some other secret information to gain an access token to the vault. This is more secure than some alternatives, but further investigation reveals that the solution is simply introducing a new secret zero by a different name because now the vault token needs to be protected. It seems like no matter how hard you try, there will be a secret zero that must be protected.

Avoid Secret Zero Problems by Using Strong MFA Factors in the Orchestration Layer

A better way to address the secret zero dilemmas is through the use of strong multi-factor authentication that leverages trusted systems that are already in place. A stolen credential will have no value if the machine or attacker using it can’t be authenticated.

CyberArk Conjur 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. To authenticate secret requests, the solution uses multiple attributes only available to trusted containers, such as the IP address range assigned to valid containers, securely random UUIDs, cryptographic keys, role, name, and other automatically generated/configured attributes in the orchestration system of choice. An application presenting only one of these factors is not enough to authenticate it. The presence of just one of these factors presented by an application would not be reason enough to authenticate it. Multiple factors must be presented for an application to be considered bona fide.

How to Replace Secret Zero With Strong Native MFA

The most important step in the container security process is to establish the identity of client containers, so it is important that this process be as strong as possible. Conjur provides a container authenticator that issues strong identity credentials to containerized applications running on platforms such as CloudFoundry, Pivotal CloudFoundry, Kubernetes, or OpenShift.

The Conjur Authenticator provides two operations: login and authenticate. The login operation is performed once by each client container to obtain a signed certificate for the life of the container. When using Kubernetes or OpenShift, the certificates expire after three days and the login process must be repeated to get a new one. This is all handled transparently by the sidecar authentication client.

The login operation uses the container platform’s APIs to install the signed certificate out-of-band and out-of-the-normal request flow to resist spoofing. The authenticate operation is performed regularly by each application to obtain a short-lived IP-restricted (not currently supported in the Kubernetes authenticator) access token. The token is encrypted with the client’s public key and delivered over a mutual TLS connection, which prevents eavesdropping and allows both the client and server to confirm one another’s identities.

Each authentication call will use the certificate installed during the login process to request a new short-lived access token. The IP address restriction prevents the token from being stolen and used outside of the container cluster. The encryption ensures that an attacker cannot use a token without having access to the private key that resides in the client container’s memory space. With these authentication and security methods in place, no single secret can unlock everything, and containers can be dynamically created without a large administrative overhead.

Conclusion

There are a lot of different ways to secure secrets, and unfortunately, a lot of them hinge on keeping one secret protected, leaving their system’s security clinging precariously to the protection of that single secret. A more elegant secrets management solution will use the underlying orchestration platform and tools rather than requiring operators to go through more processes and to install extra modules only to end up with another secret zero to protect.

It’s Easy to Get Started

If you want to learn more about how the Conjur Kubernetes-native integration works read John Tuttle’s “Kubernetes Authentication with Conjur” blog post. More details on Conjur Enterprise integrations can be found in our documentation. You can get started immediately with the hosted version of our Conjur Open Source tutorial. This tutorial will take you through the basics of creating a security policy, machine identity, and secrets management with Conjur Open Source.