Kubernetes Authentication ‘Solved’: SPIFFE/SPIRE Move to CNCF Incubation

It’s been just over two years now since the SPIFFE (Secure Production Identity Framework For Everyone) and SPIRE (the SPIFFE Runtime Environment) projects joined the Cloud Native Computing Foundation (CNCF), and now the projects have moved on from the sandbox level to the incubation level, joining numerous incubation-level projects, such as OpenTracing, gRPC, Linkerd, Rook, etcd, CloudEvents, Argo, and more. The move signifies that the projects have met a number of requirements, such as a diversity of maintainers and production use-cases, and have passed a security audit, which resulted in no critical errors.

When we last caught up with SPIFFE/SPIRE during Kubecon+CloudNativeCon North America 2019, they had just launched a number of features into alpha, including bringing federated identities to distributed architectures. Now, those features are all generally available and stable, and the projects are ready to run in production, at scale, and in a wide range of use cases, said SPIFFE and SPIRE product manager Andres Vega.

“We’re talking about all the advanced use cases of federating to cloud provider services, replacing secrets, and going into databases without requiring a username and password. All of this has opened up a bunch of possibilities. For the most part, authentication within Kubernetes is solved, and if you go to a cloud provider, they have their native security controls, but the challenging parts are the hybrid use cases,” said Vega in an interview. “We found that [SPIFFE and SPIRE] inserts right in and people are coming to SPIFFE and SPIRE to get started on complex things. In a way, it’s been a Rosetta Stone of unlocking all this and bridging the gaps between the modern way of doing things with all the other traditional ways of authentication where you were relying on using secrets.”

Vega sent a full list of features that had been updated since last November in an email:

• SPIRE Federation for the use case of interoperability between organizations, such as between a cloud provider and its customers
• SPIFFE Federation with SPIFFE Compatible systems, say a SPIRE deployment to a service mesh
• OIDC Federation to remote systems such as public cloud provider services and secret stores that are OIDC-Federation compatible
• Support for multicloud topologies with Nested SPIRE
• Database x509 authentication
• Overhauled existing client libraries to make sure they are idiomatic (go-spiffe, java-spiffe, and c-spiffe)
• Improve the performance and reliability of automated registration entry management when running SPIRE in Kubernetes

Between the two projects, SPIFFE provides a security specification for securely identifying software systems, while SPIRE is an implementation of the SPIFFE APIs, providing verification of workloads. Beyond the general availability of federated identity, the projects have added a number of features since first joining the sandbox level, including horizontal scaling, support for non-SPIFFE-aware workloads, support for bare metal, AWS, GCP, and Azure, among others, and integrations with Kubernetes, Docker, Vault, MySQL, Envoy and more. On this last point, Andrew Harding, SPIRE maintainer and a principal software engineer at Hewlett Packard Enterprise (HPE), says that SPIRE’s integration with Envoy means that SPIRE has a foot in the door, making adoption quick and easy.

“There’s a lot of existing deployments and service architectures out there that are already using Envoy, so being able to seamlessly just plug in SPIRE as the source of identity for Envoy has been a huge boon to adoption of the project in general,” said Harding.

SPIRE’s ability to work with Envoy has also led to it being used to provide identity with Istio, the open source service mesh built using Envoy for its data plane. Harding pointed to a burgeoning project by IBM that uses SPIRE to provide the identity plane, and Vega remarked on the challenges overcome by using SPIRE.

“What is challenging about Istio is that Istio’s identity model is Istio specific. If you want to give things names or identities, you’re constrained to do so off Kubernetes objects. You can say this thing is represented by the service account or this namespace, but you cannot do this for properties from the underlying infrastructure via Google or AWS, or you cannot do it from application-level metadata, which is the flexibility that SPIFFE provides,” said Vega. “Part of the motivation from IBM and others who have similar efforts is they want a more platform-agnostic way to give identities and have things on the mesh communicate off the mesh.”

In addition to new features, a number of things have been refactored, such as the client libraries for Go, C, and Java, all of which have been overhauled to simplify adoption. Vega also noted that the team had refactored the SPIRE APIs to pay down the technical debt and make it easier to solve for future planned use cases like serverless. The new APIs, he said, would be available in the upcoming July release.