The Secret Zero Problem
I have talked to a number of security conscious professionals across a wide range of professions. Their backgrounds and job functions vary, but they all have a common question, “what if someone hacks __”. There is usually a good answer to this question that details how __ is protected by the security solution, but this line of questioning usually continues for a few more iterations until we arrive at a scenario that few security products have an answer for. The “what if someone hacks __” questions usually stop when we arrive at the ultimate secret that protects all other credentials, this is secret zero. What if someone hacks secret zero? The answer is… You are owned!
Organizations struggle to securely authenticate client requests for services and to securely distribute secrets without introducing more credentials that need to be guarded. Typically secrets management solutions rely on a master key or secret zero that can unlock other credentials, allowing an attacker to move laterally and eventually own everything in the organization. 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, so…you get the idea. This scenario is often compared to Russian nesting dolls, where opening one doll reveals many more. Securing secrets with secrets only gives the illusion of security as one vulnerability is exchanged for a different one.
Some Approaches to Secret Zero
Some secrets management solutions claim to solve the secret zero problem 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 secrets vault. This is more secure than some alternatives, but further investigation reveals that the solution simply introduces a new secret zero by a different name. The combination of the role id and a secret id create a access token that needs to be protected, a secret zero.
Our Approach
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. 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. A stolen credential will have no value if the machine or attacker using it can’t be authenticated.
How Conjur Provides Strong Container Authentication
The most important step in the container security process is to establish the identity of client containers. If a container requesting secrets can’t be authenticated, then it shouldn’t be authorized, so it is important that this process is as strong as possible. The Conjur container authenticator certifies clients and issues strong identity credentials to containerized applications running on platforms such as Cloud Foundry, Pivotal Cloud Foundry, Kubernetes, or OpenShift.
The Conjur Authenticator provides two primary functions to establish and verify identity: login and authenticate. Generally the login operation is performed once by each client container to obtain a signed certificate valid for the life of the container. 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.
Note: When using Kubernetes or OpenShift, the certificates expires after 3 days and the login process must be repeated to get a new certificate. This is all handled transparently by the sidecar authentication client.
The authentication operation uses the certificate created by login to obtain a short-lived access token that is restricted for use based on multiple factors that only the legitimate container could poses. These restrictions prevent a compromised token from being used outside of the container cluster by an attacker. This token is also encrypted with the client’s public key and delivered over a mutual TLS connection, preventing eavesdropping while allowing both the client and server to confirm one. 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. These authentication and security methods ensure that access tokens are properly secured, and even if a token is compromised, it cannot be used unless the client container presenting it has been properly authenticated with multiple factors native to the container orchestration systems.
Conclusion
There are many different ways to protect secrets, but most have at least one powerful secret that, if compromised, can allow attackers to move latterly and rifle through a company’s data. It is difficult to secure something without secrets. For this reason, CyberArk Conjur uses strong multi-factor authentication to establish the true identity of the container presenting the secret or access token. This world-class solution uses the underlying orchestration platform without requiring operators to go through extra process or installing extra modules – which would otherwise create another secret zero to protect. With Conjur, having a single secret or having one factor is no longer enough to be granted access to the keys to the kingdom.
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 integrations can be found in on our page. You can get started immediately with 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. If you use Google Cloud Provider, deploying Conjur Open Source only takes one click in the GCP Marketplace. If you get stuck, no worries, help is always available on the CyberArk Commons.
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.