Aembit’s (unofficial) motto is to “Manage Access, Not Secrets.” That being said, in many cases, we do need to deal with secrets to enable access management. As a result, customers often ask how we differ from secrets management products.
First, many solid secrets management products and features are available in the market. Second, it is not straightforward to compare secret managers with Aembit, which is focused much more comprehensively on workload identity and access management.
However, discussing a few areas where we differ is helpful, and I want to concentrate on these aspects.
Turtles all the way down…
Installing a secret manager without all the bells and whistles switched on requires you to store a fundamental secret somehow (e.g., a root key) to unlock access to all the rest of your secrets. This situation is sometimes called “Turtles all the way down,” implying that the solution requires solving the same problem we originally started with.
To be fair, I was referring to relatively simple common implementations of secrets managers. “Best-of-breed” tools have started to provide better alternatives to using long-lived secrets for access. They prefer client workload identities for authentication (Kubernetes service accounts, AWS roles, etc.) instead of tokens. However, deploying in this manner requires operators to learn about this option and explicitly configure it.
Aembit started from the opposite end and built a secure solution by default, which requires minimal configuration rather than beginning with a less secure option and gradually locking it down.
Keys to the kingdom
Secrets managers hold multiple “keys to the kingdom” – e.g., root tokens and recovery codes and once compromised, an adversary has access to all credentials in the secrets store. That is an inherent weakness. Mitigating this risk relies heavily on your security procedures and people being very careful and diligently avoiding putting these susceptible keys in a spreadsheet or storing them on a shared network drive. Software can only partially protect from lousy security practices.
For many secrets managers, the keys used to configure them and the keys for extracting secrets are the same.
Aembit takes a different approach. Aembit Edge components require a client workload identity to access secrets but can’t do any configuration. Aembit Admins can configure the system but cannot get secrets from Aembit directly.
It’s an important distinction that Aembit doesn’t have the keys to the kingdom and thus cannot give immediate access to everything.
Operating a product vs. a solution
The majority of secrets managers are intended to be installed and managed by you, the operator. While many of these tools are simple to install, it is complex to scale them and even more complicated to secure them properly. The operational cost of following best practices is not insignificant, and it’s easy to miss critical details.
We designed and built Aembit from the ground up as a SaaS solution. Since we operate it, we take that burden and cost away from customers while enforcing best practices. Also, since we focus on delivering solutions (rather than a product), we accommodate many use cases and simplify the overall experience for DevOps and security teams.
What touches secrets?
Secrets managers release secrets to client applications. An insecure client application can leak secrets (“Game Over”).
Aembit is architected so that it doesn’t release secrets to client workloads. We intercept requests from client workloads and inject access credentials into those requests, eliminating the need for clients to access secrets.
Access vs. secrets
Ultimately, secrets managers manage secrets! They store them, release them to client applications, and sometimes rotate them. Access is essential, but it’s secondary in a secrets management story. Secrets managers have completed their job once they deliver secrets to client workloads.
However, many questions need to be answered from the moment the client workload gets the secrets.
- Who implements authentication in the client workload?
- Is it implemented correctly?
- Are you using the best practices?
- Does the client workload leak credentials?
- Are they long-term or short-term credentials?
- Is your authentication logic reviewed periodically?
- Who handles the operational aspects of configuring key rotation and so on?
Aembit’s objectives are very different from the secrets managers. Our ultimate goal is to ensure that only authorized client workloads can access server workloads. And we want to ensure we smooth as many bumps from the customer’s road as possible.
We solve secrets management, which is an integral part of any identity and access management solution. But we also solve inconsistent authentication implementation problems, mitigate the risk of client workloads leaking secrets, and the need to adhere to security best practices.
To give you an example. Suppose tomorrow, a vulnerability is found in SHA256. In that case, we will be able to bump it to SHA-3, and all client workloads relying on Aembit for authentication will start using it, while a secrets manager will only apply this to the credential aspect of access. And all client workloads will continue to use (at that moment) weak algorithms.
Summary
Secrets management products have their place, and some are gradually being enhanced to help with access problems. Aembit is a solution to access management problems, which takes care of secrets out of necessity (read: secrets management for us is a tool rather than a goal), and that’s the main difference.
P.S. The last funny bit of info. We, of course, use secrets management tooling internally where it is needed because we don’t want to reinvent the wheel. We want to invent non-human identity and access management.
Aembit is the Identity Platform that lets DevOps and Security manage, enforce, and audit access between federated workloads.
We invite you to try it today!
