Blog post image

Simplifying SPIFFE: Accessible Workload Identity with SPIRL

SPIRL is a full workload identity solution based on SPIFFE (Secure Production Identity Framework for Everyone). What does this mean? What is SPIFFE and isn’t it already for everyone? Or if not, how could “everyone” include more “everyone”?

The most important piece to understand before getting started is that SPIFFE is a specification. Relevantly, this means that SPIFFE is not itself a tool, but rather something that can be implemented in a standard way. There are open source implementations of SPIFFE, including a project called SPIRE, which we will also talk about in this post.

What does SPIFFE solve?

SPIFFE removes the need for a “secret zero” or “first secret” for workloads. In most modern configurations, API keys and other credentials need to be securely created, stored, rotated, and otherwise maintained. Whether this is done fully manually or with scripts, the management and tracking of these adds operational expense and risks outages. Instead of relying on API keys and other analogs, SPIFFE implementations securely grant services either a short-lived X.509 certificate or JWT that is automatically rotated. SPIFFE supports clusters, meshes, bare metal and other types of workloads, and can be implemented to span these at scale.

Challenges of implementing SPIFFE

There are a handful of options across the “build vs buy” spectrum when it comes to adopting SPIFFE in your environment. On the build side, you can implement your own, or you may have inherited SPIFFE in portions of your infrastructure, for example via a service mesh. Alternatively, you may invest in designing and maintaining a SPIRE deployment. On the buy side, there is SPIRL. The best solution for you will depend on your specific needs and resources: how large your infrastructure is as well as whether or not you're able to dedicate a team of experts to build and manage your solution.

Organizations that have inherited SPIFFE via a service mesh are left with islands or pockets of workload identity, without the ability to effectively span the infrastructure as a whole. Extending this functionality to services outside these islands, and even between the islands, is challenging. Effective workload identity management should mirror the SSO experience, being able to span organizations as needed.

SPIRE has an extremely flexible approach and is capable of spanning heterogeneous infrastructure in this way. While the flexibility allows for customization, it incurs significant operational cost and expertise expense to know what needs to be customized and to what degree. This likely rings similar to many default Kubernetes deployments, which are also highly customizable but require the operator to know what options have been exposed and their ideal configurations for specific situations.

This means that SPIRE and other technologies incorporating SPIFFE, while powerful, are not for everyone due to their technical and operational complexities. Small scale deployments typically take 6-12 months and more complex deployments can easily require 12-24 months to complete. In both scenarios these figures require a core team of experts to build the solution.

SPIRL implementation

SPIFFE benefits everyone, individuals and organizations, in need of service-to-service authentication regardless of scale. SPIRE is a flexible SPIFFE building block, excelling within its designated domain; however, it is not yet universally accessible due to the aforementioned challenges. SPIRL’s primary objective is to make SPIFFE, and workload identity at large, accessible to all.

SPIRL is a complete workload identity solution, providing a foundational framework upon which all higher-level production controls are constructed. We provide opinionated attestation and key management configurations out-of-the-box based on best practices tailored to multiple platform and provider configurations. For example, by specifying the platform type and provider when deploying SPIRL agents, we can make the correct choices and get you to production without involving lengthy research and design processes. Our goal is to make it so everyone can be production-ready, quickly.

SPIRL also provides centralized management APIs, workflows, and tooling that allows you to deploy both across clusters and providers. For example, you can deploy agents in staging and production, in your on-prem data centers and in Google Cloud, and manage the entire deployment through a single pane of glass. With auditing, SSO, and two-person rules, complex workflows can be built and enforced, ensuring safe and secure operation of your workload identity solution.

The workload identity revolution

These pivots in service-to-service security likely feel familiar. Just as human identity broadly shifted from password management techniques to leveraging centralized identity providers with an SSO-like experience, service-to-service security is shifting from secrets management techniques to more centralized workload identity providers, affording SSO-like experiences through federation. The change eliminates the need for managing and sharing secrets, which has become a major threat vector over the last five years. It also provides security and platform teams with the observability they need across their environments to ensure safe and secure operation of their internal services.

Where to learn more?

Check out the SPIFFE documentation, book, and slack channel to learn more about workload identity. Want to learn more about SPIRL? Please reach out to us using our contact form! We’d love to hear from you.