Scytale Launches SPIFFE-Based Service Identity Management
Microservices in particular provide growing challenge for DevOps teams: How individual components can identify and trust other parts of a software system.
SPIFFE, which stands for Secure Production Identity Framework For Everyone, is an open source framework for authenticating service identity across microservices and servers. It uses SPIRE (SPIFFE Runtime Environment) as a central server for handling identity.
The SPIFFE/SPIRE project became a Cloud Native Computing Foundation sandbox project last March.
Now Scytale, the founding sponsor for the SPIFFE/SPIRE projects, is launching Scytale Enterprise, a cloud-based subscription based on SPIFFE/SPIRE to standardize service authentication across cloud, container, and on-premise infrastructure.
“According to our research, the need to unify access controls across cloud and on-premises infrastructure is the most significant challenge organizations face today with responsibly delivering business services,” noted Steve Brasen, research director with Enterprise Management Associates (EMA).
He lauded Scytale’s approach of unifying access controls to services across complex, hybrid IT ecosystems.
“We see this as an unsolved problem and an increasingly difficult challenge,” said Andrew Jessup, head of product at Scytale, adding that most identity-management systems focus on authenticating users not services to each other.
“If I’m a bank and I have a mobile app, I might be delivering cloud-based functionality, but other parts still using existing infrastructure and services that I have in my data center. Rarely am I building things entirely in the cloud or entirely on-premise. When I’m talking about a whole solution, I’m talking about a mix of those.”
And it’s not just about services talking to each other between on-prem and cloud, but also on multiple clouds. There’s also a whole host of concerns that come from middleware.
“Maybe I have Kubernetes running part of my system. Maybe I have a PaaS system like Cloud Foundry. Maybe a team has developed its own system,” he said.
“We have more and more of these discrete services. When we talk about service-oriented architecture and microservices, instead of passing data structures around in memory, we’re passing information around over the network and often the Internet.
When they move to cloud, they find they have multiple identity providers,” he added. “It’s really hard for something running in Cloud Foundry and Azure to authenticate itself securely to something running on Kubernetes and AWS. These things don’t work together at all. There’s no trust-bridging between these different systems. For security engineers, this is becoming a real headache.”
In CNCF Sandbox
Since becoming part of CNCF, more companies such as Uber, Pinterest and Square have become active contributors.
SPIRE is not the only implementation of SPIFFE. Others are Istio Citadel and Hashicorp Consul. Consumers of SPIFFE include the Envoy proxy, Pinterest Knox and the Ghosttunnel proxy.
SPIFFE provides a standard for service IDs. These SPIFFE IDs and are implemented as Uniform Resource Identifiers (URIs) and a standard for encoding them in a cryptographically-verifiable document called a SPIFFE Verifiable Identity Document or SVID. It includes an API specification for issuing and/or retrieving SVIDs.
SPIRE, now called the runtime implementation rather than the reference implementation:
- Performs node and workload attestation.
- Implements a signing framework for securely issuing and renewing SVIDs.
- Provides an API for registering nodes and workloads, along with their designated SPIFFE IDs.
“If you have a workload on a machine in the data center or in a pod in Kubernetes, we have a common language to express identity in a policy-driven way. It allows us to move away from what’s called bootstrap identification — having a password that’s embedded in an application when it’s deployed,” Jessup said.
It can basically fingerprint a software system.
“We can create an identifier independent of whether it’s running on Amazon or [wherever.] We can do this across this very heterogeneous environment. We can create a common directory of workloads and identities no matter where they happen to be running.
Then it integrates with other identity providers.
“We’ve started to build this identity exchange infrastructure. To do this manually would require you to have long-lived tokens… What we’re now able to do is to use a sidecar server to allow a workload to exchange a short-lived identity in something like OpenDirectory or an Amazon S3, for example. Now what we’re able to do is to govern in a very precise and auditable way exactly what’s getting what identities and the policies around how that is governed as well. This workload needs a short-lived credential to access Amazon to write material to a particular S3 bucket or something like that,” he said.
It’s a very specific set of privileges. Then it interacts with the other system to provide that credential.
“We’ve brought sanity to this mess of different identities. Now you have a single place where you can say, “Tell me what this workload is and how it’s able to present itself to all these different systems,” he said.
“We’re also enabling development teams to build their own authentication layer based on Spiffee and Spire. They can build more robust zero-trust architectures on these identities.”
Scytale also announced a $5 million investment from Bain Capital, Bessemer Ventures, TechOperators, and Work-Bench.
The company will be demonstrating Scytale Enterprise at RSA 2019 Booth 103.
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature Image: “Valentine’s Day Design (nicked from Chris Gardner)” by Tim Regan. Licensed under CC BY-SA 2.0.