What is Aembit?
Aembit is Workload Identity and Access Management. Another way to say it is that Aembit is part of the Workload Identity and Access Management market category (Workload IAM). We think Workload IAM is a developing subcategory of the broader IAM market. If you’ve never heard of Workload IAM, that’s OK. You’re in good company.
So why did Aembit place itself in a market category no one’s ever heard of? Great question! We didn’t just make up that term without some context, and we think Workload IAM will become a “big thing.” Why? Because the broader IAM market has widely accepted terminology for various product categories. For example, Workforce IAM generally refers to technologies that help employees log in to IT systems at work. Customer IAM helps businesses manage customer identities and log-ins. There are many other types of identity-related solutions, but these are probably the most well-known.
What is Workload IAM?
OK, so what is Workload IAM? Another good question. Let’s first define “workload” since people apply that term in various ways across the computing industry.
Suppose you’re a developer or involved in DevOps. In that case, you might have run across a definition from Kubernetes:
A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods.
I like this definition because it is clear and concise. The only downside is that it’s particular to software running in the Kubernetes ecosystem.
At Aembit, we define workload a little more broadly: A workload is any program or application that utilizes computing, data, networking, and storage to perform one or more tasks. Some examples of workloads include:
- Custom applications you run in your environment (including in Kubernetes),
- HTTP-based APIs from third-party SaaS providers or API gateways.
- Databases (or, more specifically, database management systems).
- Application services provided by hyper-scale cloud vendors.
Aembit applies mainly to workloads that access each other via a TCP/IP network. Some terms developers use to describe this type of scenario are “application-to-application” or “server-to-server.”
Now that we have the background context on identity and access management and a definition for the term workload, we can understand what Aembit does: Aembit gives identities to your workloads, authenticates them, authorizes them to access each other based on policies you set, and logs all accesses and access attempts for auditing and analytics.
Aembit’s Raison d’être
Why does Aembit exist? As is often the case when building software systems, one tends to repeatedly see patterns of problems and solutions. The team at Aembit has worked on software products and cloud services at some of the most well-known security companies in the world. Usually, the story goes something like this:
- We create a new software feature or product.
- That software depends on various services, like a database (or several databases), an internal REST API, a third-party service, like Amazon S3 for file storage, or a payment gateway like Stripe.
- Our software needs credentials to authenticate to these services, sometimes with a password or API key. Other times, authentication is more sophisticated and involved – think OAuth2 and JWT, or even PKI and certificates.
- Implement authentication logic in software, cross our fingers, and hope we did it correctly so our app will be secure.
- Figure out where to put all these credentials so they don’t get leaked over the internet (environment variables? a secrets manager? a key manager?).
- Figure out how our software will access these credentials once we find a place to put them. Oh, that probably means we need a credential to access the credential manager! (I hope you see the irony in that… and are familiar with recursion!)
- Make sure we have a way to monitor and audit access to said credentials.
- This list could go on for a while, so I’m just going to cut it here.
Once we unpacked all of these problems, what did we do to solve them? We usually integrated multiple systems, like our cloud provider’s IAM, secrets-management tools, audit logging, and others, into a loosely coupled and complex “solution.”
Unfortunately, this type of apparatus is challenging to implement, expensive to operate, and hard to evolve because it’s difficult to test in a repeatable, automated fashion. Another major downside is that it isn’t always easy to understand, especially for newcomers to the DevOps team.
Boundaries
There is one more crucial problem that a homegrown system like this doesn’t address well. That’s the fundamental insecurity of a software system with components widely distributed beyond the boundary of a particular cloud provider or enterprise data center. To illustrate this problem by example, imagine that you’re running your workload in AWS. Maybe you even have AWS experts on staff who can help with security concerns like IAM. But, you need to connect to a database in your data center. Or, you want to use BigQuery, which runs in Google Cloud and Google has its own IAM. You need to fetch customer data from Salesforce via a REST API. And so on.
Aembit exists to simplify and accelerate application delivery by handling workload authentication, authorization, and logging for you. Our goal is to provide seamless and secure access from your workloads to all the services they depend on, like APIs, databases, and cloud resources, regardless of your chosen technology stack.
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.
