Our industry tends to abstract concepts too much (and wrap them in marketing terms to boot). I often find myself trying to decode what some security product does by reading a lot of the company’s material when just one article should have sufficed.
As a result, I decided to write about Aembit’s product in terms that would have made the most sense to me as a software engineer. And I hope that you can read this article and have a pretty good grasp of what we do, why, and how we do it.
Product
Our market is “Workload Identity and Access Management.” If you scratch the surface of that term, it all boils down to the problem that you need to make sure authorized apps on one side of a request can access apps on the other. I find it interesting that people in this new market emphasize the abstract part (the word “identity”) while they take the concrete problem of “access” for granted.
There are a lot of aspects of access. Aembit concentrates on application access – authentication and authorization rather than physical or network access.
The term workload is quite vague. Nobody knows precisely what other people mean by it. We wrote another article covering what we consider a workload: A custom app, SaaS API, Database, and a Lamba in AWS, an edge device. As you can see, it’s almost any piece of software running anywhere.
The main problem we solve is authenticating workloads and granting access only to authorized services based on policy.
What does our product offer?
All these workload identities or even authentication between workloads are well and good. However, the critical question is how the product can make my (or other people’s) life easier.
We heavily concentrate on three overlapping groups of people. Each of these groups will get value from our product slightly differently.
Developers
- The problem which we solve for developers is the complexity of authentication. I spent the last twenty years in security, and it often boggles my mind how many ways you can implement authentication wrong and how hard it’s to wrap your head around the topic. So what we give to developers is the ability NOT to think about changes to OAuth 2.0 related to PKCE, recommendations about algorithms used to sign X509 certificates, or learning how Google STS works. Instead, you get this all in a batteries-included package.
DevOps
- Many (especially older) companies still maintain a spreadsheet with their list of workloads. This list is never complete and never up-to-date. We provide a central workload directory, so you know what, where, and when it runs, even if it spans clouds and environments.
- We add a lot of visibility to help you understand which workloads talk to which services.
- Another widespread problem is all these environment variables, files, and secrets managers with sensitive data flying around. We remove the need to manage secrets (provision them into the workload, rotate them, etc.).
Security
- Secrets touch a lot of hands and a lot of software, even in companies that manage their secrets carefully. Our system ultimately manages access rather than secrets. The idea is to prevent secrets from being accessed by people or, even more interesting, your applications. We have a closed-loop system that takes care of acquiring and provisioning credentials when and where they are needed.
- In some cases, we allow you to eliminate long-term secrets.
- We decrease risk by ensuring that only trusted apps can use their credentials, reducing the chance that a malicious workload running outside your environment can use a leaked secret to access services.
- And we give visibility into what workload accessed what other services, and when.
Why should developers care? (especially those in DevOps)
Let me start from a tangent and come to the main point.
I remember when software builds were done by some crazy bash scripts running overnight. Gradually, companies threw away these scripts and replaced them with Jenkins (or similar). Of course, that practice grew complex, too, and became a mess. And companies switched to CircleCi, GitHub Actions, Drone, and other continuous integration platforms (CI), which solved their build-time needs cleanly while requiring 1/100 of the scripting investment, and 1/0 of managing your CI system.
I believe access, and authentication, as a critical part, is going through a very similar transformation. People used to implement all kinds of wild home-grown authentication/access solutions. Then, gradually, companies switched to standards, like SAML and OAuth. The next obvious step Aembit works on is externalizing the complexities of these authorization protocols and delivering them as part of a platform.
So, similar to CI, you can get Workload IAM in 5 minutes. I am not kidding about the setup in 5 mins. I did a speedrun of our product and got it working end-to-end in less time.
Please, don’t roll your own (weak) solution.
It’s common for inexperienced software engineers to severely underestimate the complexities of what they are getting into.
Indeed, you could implement a simplistic authentication solution on your own. Just create a long-lived API token, copy and paste it everywhere, and send it to Ops, who will stick it into some environment variable. Viola, we have two apps talking to each other.
And in so doing, your secret traversed three people, one of whom accidentally put it in Evernote. Further, that secret can now be accessed and leaked by your app. By the way, it’s a long-lived secret, and the last person who remembered how to recreate it just left the company.
That may sound a bit exaggerated. I hope your company has better security practices. However, developers could do many things wrong, even after spending a non-trivial amount of time to roll out the solution.
Summary
The bottom line: If you think about authentication between apps, if you don’t know exactly what is running where, or if you worry that your secrets may leak, you may want to look in the workload IAM space.
***
Aembit is the Identity Platform that lets DevOps and Security manage, enforce, and audit access between federated workloads. To learn more or schedule a demo, visit our website.
