Cyberark Conjur vs Hashicorp Vault
In 2021, IBM estimated that 20% of all security breaches began as a credential leak, making it the most common, and most costly, initial attack vector. This indication coupled with the indication that the implementation of Zero Trust infrastructure cuts the average cost of a breach nearly in half indicates that proper Secrets Management hygiene is a critical consideration for reducing breaches and the subsequent costs.
What is Secrets Management?
In some cases, a Secret may also be considered a piece of confidential information, however this information is arguably handled a bit differently and is out of scope for this conversation. In the context of this discussion, a Secret is considered a piece of information used for authentication purposes to a workload. This may include, but isn’t limited to, things like usernames and passwords, X.509 certificates, tokens, or API Keys. Secrets Management refers to the lifecycle of these and includes acquisition, rotation, revocation, and auditing of this information. Authentication may be initiated by a human, human to machine, or via another workload, machine to machine. With a parabolic increase in the number of connected devices in the last 5 years, maintaining the Secrets Management lifecycle becomes exponentially more complex and increases the risk of a credential related breach.
Secrets Management or Privileged Access
Frequently, the difference between Secrets Management and Privileged Access Management creates some ambiguity, especially when it comes to tooling and tooling capabilities. While there is certainly some dual functionality for many PAM solutions, knowing the primary business, technical, and regulatory objectives are critical when picking tooling.
Secrets Management deals with the day to day use of credentials and is, optimally, as automated as possible with a focus on Machine to Machine. When establishing a Secrets Management strategy, the goal is to know Who, What, and Where for both the Client and the Object in an automated fashion, leveraging the concept of Zero Trust to distribute the Secret with only the required permissions. Concretely, for example, a Kubernetes cluster should know where to retrieve the credential in a specific vault and the vault should know where to return the specific Secret, typically a specific pod within a namespace. If the location or the content requested by either the cluster or the vault does not match, then the request should be denied. Each time this request is initiated, the identity of the client should be authenticated before authorizing the credential retrieval.
Privileged Access Management is typically something that is needed outside of Business as Usual and day to day operations. Commonly, it is needed for break glass procedures or change management where atypical human access is required, perhaps for debugging or implementing a workaround. This still requires both client and object to have an awareness of Who, What, and Where and for authentication each time, but the frequency of the intervention is reduced and the use pattern is less predictable. In such cases, a different level of monitoring and logging may be required.
Dynamic Credentials
As computing becomes more powerful, the time to break a key or a password is drastically reduced, especially when considering Shor’s algorithm. Factor in that statistically, only half of the password cracking attempts are required to actually crack a password, and the need for short lived credentials becomes blatantly apparent. By generating credentials on the fly for consuming workloads which are limited to a number of uses or a very limited timeframe ensures that even leaked credentials, whether the leak is human, pipeline, or machine based, credential leaks become an inherently mitigated attack vector with a reduced blast radius.
Secrets Management Tooling
While cloud native vaults, such as AWS Secrets Manager and Azure Key Vault, can, and should, cover a number of use cases, frequently in the cases of multicloud, hybridcloud, or regulatory cases when the location of the key itself is a concern, a more agnostic approach is typically preferred. There are also instances when cloud native tooling cannot be leveraged, for instance application level Secrets on Azure Kubernetes Service. Currently, there are limited tools on the market for Secrets Management, particularly concerning ephemeral workloads, and it is largely dominated by CyberArk Conjur and Hashicorp Vault.
Both tools maintain their proponents and their arguments for and against Vault and Conjur. Foundationally, both products share many characteristics. Both solutions leverage policies to ensure the Principle of Least Privilege and have the ability to make Access Control Lists more granular based on identity and location. However, when looking at either tool there are objectively subtle differences that distinguish these competitors from each other, and may make them more suitable for certain environments over others.
CyberArk Conjur
CyberArk is a tried and true solution in the Privileged Access Management space. Its Cloud Native solution for Secrets Management, Conjur, is available in both Open Source and Enterprise. As with most solutions, the Enterprise version offers more features and has the possibility to integrate with CyberArk as well as more enterprise requirements including SIEM integration, autoscaling, High Availability, and auditing capabilities.
Deployment
Deployment of Conjur is done via Docker image or AMI for the Enterprise version and Open Source, but can also be acquired by AWS Marketplace or GCP Marketplace for Open Source. The image may be run in a Docker container or leveraging Kubernetes or OpenShift. However, if running a Highly Available setup, which requires multiple Nodes, an orchestrator is clearly necessary to ensure HA.
Conjur also requires a Postgres database per conjur server for storing secrets, which also runs in a pod. This requirement offers a certain amount of overhead and adds some concern about the persistence of data in the event a pod goes down, which should be mitigated in a HA setup.
Workload Authentication
In order to authenticate workloads, Conjur relies on application enrolment and returns a Host ID and an API Key. API Keys can be rotated upon request and have specified policies dictating permissions. Other authentication mechanisms may also be configured and leveraged, such as the major public cloud platforms native authenticators, JWT, and OIDC.
Feature Pros
Conjur’s Secretless solution ensures that Secrets do not remain in memory any longer than the connection is open, and therefore reduces the attack surface of a potential credential leakage as a result of the limited retention. Using a socket, Secretless is achieved by leveraging a Broker, a short lived agent, that can authenticate to the vault and communicate the secret to the target.
The other advantage is the ability to directly update a Kubernetes Secret via the Secret Provider using an init container on startup. This ensures that the Secret is only updated as necessary and keeps these secrets out of source code. By using a Kubernetes Secret, however, the Secret is written to the memory of the bound Service Account and an updated Deployment would be required to update the Secret. There’s no question that this is preferable to a manifest with the secrets saved in plaintext or saved locally as environment variables.
Feature Cons
The most notable feature missing for Conjur is autorotation. According to the documentation, Rotators are currently available for Postgres and AWS IAM with no indication of building others. While the PAM solution seems to have a robust auto rotate functionality, as a cloud first focus with support for ephemeral workloads and microservices, the requirement for manual rotation is incongruent with the nature of the environment it supports.
Hashicorp Vault
Hashicorp is a relatively recent disruptor to the Secrets Management space. The product focuses uniquely on Cloud Native solutions with their Swiss army knife of a vault which is targeted at leveraging Zero Trust and dynamic credentials. While Vault was initially positioned for Secrets Management, it is also evolving into the Encryption and Key Management space, as well.
Like Conjur, Vault is available as both Open Source and Enterprise versions. While High Availability and audit logging is available in the Open Source version of Vault, more granular policies, secure multi-tenancy, and LDAP integration are part of the Enterprise version.
Deployment
Deployment of Vault can be done either by image or binary, depending on the technical requirements. For data persistence, Vault can be deployed using Integrated Storage, which requires no additional nodes or using Consul, another Hashicorp product, if there is a requirement to separate out the data at rest. Both integrated storage and Consult provide automated snapshots to help with backups. Overall, Vault is straightforward to roll out and can be deployed on the infrastructure of choice. By leveraging the Auto-unseal feature, there is no concern about manual ceremonies for cryptographic keys.
Workload Authentication
By default, Vault leverages a token system with a specified Time to Live relying on policies to dictate permissions. Tokens are no longer valid and must be regenerated at the end of their TTL. Other authentication mechanisms may also be configured and leveraged, such as the major public cloud platforms native authenticators, JWT, and OIDC, which are verified for each credential retrieval.
Feature Pros
Vault is a veritable Swiss army knife of Secrets Management. Between the various authentication methods, the dynamic credential engines, data encryption possibilities, and the secret wrapping, companies have all the tools required for a robust, dynamic secrets management solution. The product reflects the dynamic nature of ephemeral workloads and appears to provide a solution that “assumes breach” by making credentials as short lived as possible, meaning that even if credentials are obtained, they are pretty worthless by the time they can be used for authorization.
For Kubernetes, the Injector sidecar leverages the mutating webhook, looking for create and update events, to inject updated credentials as required allowing containerized applications to leverage dynamic credentials. While credentials may be written to memory and accessible by resources tied to the Service Account, the ephemeral nature of the credentials themselves drastically reduces the attack surface of a breach.
Feature Cons
When it comes to static credentials, it is clear that Vault is a solution targeted towards more dynamic solutions. Many companies driven by larger regulators or security frameworks adopt internal policies regarding Secret rotation frequency. While it is possible to find this information based off of Secret metadata, it would require a bespoke solution to parse the audit log ensuring proper log retention.
The dynamic and highly configurable nature of the tool also means that there is a steep learning curve when leveraging Vault. With all of the bells and whistles and Vault more recently becoming mainstream, sometimes it takes a bit of searching before finding best practices. That said, there is a robust and active developer community behind Vault with easily accessible documentation.
So, Conjur or Vault
At the end of the day, it really comes down to the architectural needs and ambitions. If there is a focus on securing more static credentials, a need to integrate with a PAM solution and a willingness to accept a bit more overhead in terms of infrastructure, then Conjur may be the better option. If the architectural needs dictate that dynamic credentials, less overhead, but a steeper learning curve are preferable, then Vault should be a consideration.
As with any DevSecOps tool, though, it’s about the adoption and the culture surrounding the tool which will dictate the program’s success.