Workload identity is a necessary but relatively new area of cybersecurity, and customers and vendors are trying to understand the core threats, problems, approaches, and pitfalls therein. When talking to customers, they occasionally ask us questions about SPIFFE and SPIRE. This article will briefly overview SPIFFE and SPIRE and explain how Aembit differs from them.
SPIFFE/SPIRE Primer
What is SPIFFE?
“SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Systems that adopt SPIFFE can easily and reliably mutually authenticate wherever they are running.”
Here is a link to the official overview of the SPIFFE specification.
The SPIFFE documentation describes how they issue identity documents, how they are structured and validated, how different entities are related, and what API each component should provide. There is quite a lot of documentation over there. I recommend starting by watching their video, where the SPIFFE team explains the problem they solve (establishing workload identity) and their high-level architecture.
The bottom line is that SPIFFY specifies how to build a system that issues and validates workload identities.
What is SPIRE?
“SPIRE is a production-ready implementation of the SPIFFE APIs that performs node and workload attestation in order to securely issue SVIDs to workloads, and verify the SVIDs of other workloads, based on a predefined set of conditions.”
Here is a document that describes SPIRE.
SPIRE is one implementation of the SPIFFE specification. However, numerous others exist (lstio, Hashicorp Consul, Kuma, and others). Interestingly, we noticed that customers often say SPIFFE while referring to a specific implementation, i.e., SPIRE. It’s a minor confusion and could be clarified during a thorough discussion. However, it is essential to distinguish between specification and implementation to understand this topic.
Identity and Access Stack
Before comparing and contrasting SPIFFE/SPIRE with Aembit, we need to define our problem space to compare apples to apples.
When people discuss Identity and Access, they often concentrate on just some aspects while completely ignoring the rest. However, this market has multiple distinct areas. I read several articles where people defined the relationships between layers of this problem. For example:
- https://www.oneidentity.com/video/learn-where-to-start-with-identity-and-access-management8108907/
- https://www.watchguard.com/docs/whitepaper/wg_trusted_identity_wp.pdf
Unfortunately, there isn’t a standard, well-defined model for this. As a result, I will lay out how I see the workload identity space.
This pyramid below illustrates customers’ needs. At the top of the pyramid are high-value problems that customers are most interested in solving. However, these problems can’t be solved in isolation. Complete solutions require the lower part of the pyramid to be taken care of first. That forces customers to concentrate on these lower layers, which are less valuable on their own but essential to developing high-value solutions.
Workload Identity is the base of the pyramid. It has specific problems that need to be solved, including identity bootstrapping, workload attestation, and identity lifecycle management.
Authentication relies on the identity layer being solved. And it has several aspects of authentication between first-party and third-party workload.
Access consists of defining access and authorization policies, policy enforcement, and logging access and authorization events.
Access analytics layers analytics on top of access that provides a way to make sense of what is happening with access in the customer’s environment.
And finally, governance ensures that the whole ecosystem follows defined security practices.
Aembit vs. SPIRE
The most crucial difference between Aembit and SPIRE are layers of this pyramid that each product helps solve.
SPIRE concentrates on the Identity layer (solving identity bootstrapping, issuance of identities, and attestation). It requires integration with other tools to solve problems higher up the stack. For example, you may integrate SPIRE with Envoy for authentication, which you then integrate with something like Kuma to build a service mesh.
Aembit takes care of the customer needs through the whole pyramid: Identity, Authentication, Access Management, and Access Analytics.
Is Aembit an implementation of the SPIFFE specification?
We considered this. However, ultimately we decided against it.
SPIRE has excellent solutions for some problems, namely identity bootstrapping and attestation. And we implemented very similar approaches to address those problems.
However, there were three areas where SPIFFE/SPIRE would have created more issues for our customers than it would have solved:
- One of the customer cases we solve is access to SaaS APIs from hosted client workloads. SPIFFE/SPIRE machinery operates only when the server workload has a policy enforcement point: (read: can use client workload identity to decide whether to allow or deny access). This approach doesn’t work for 3rd party SaaS products because they don’t have a way to install such policy enforcement points.
- Overall deployment architecture (designed to run entirely in the customer’s environment) didn’t match our goal of running most of our product as a SaaS offering.
- And finally, SPIFFE is designed around a “cooperative” workload model. That means that customers need to be willing and able to modify their workloads and services to work with SPIFFE implementations like SPIRE.
None of these issues are insurmountable. They have workarounds. However, the expertise, cost, and complexity of addressing these issues outweigh any benefits for most organizations.
Can Aembit use SPIFFE Identities?
We don’t currently use SPIFFE identities. However, we do integrate with other identity systems using Workload Identity Federation. For example, we can federate Aembit identities with Google Cloud identities to enable client workloads to access Google Cloud services securely without requiring customers to provide any long-lived secrets.
If we need to integrate into the SPIFFE ecosystem, we will add functionality to exchange Aembit identities for SPIFFE identities and vice versa. Please let us know if your organization is interested in this.
Summary
SPIFFE is an excellent and well-thought-out specification, and SPIRE is a solid implementation of this specification. It is a great tool. However, it’s not a standalone solution. You need to integrate it with other tools to provide material customer value.
Aembit is a complete, vendor-supported, end-to-end solution to Workload Identity and Access Management problems.
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!
