Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Production Identity Framework SPIRE Graduates to CNCF Incubator

Production Identity Framework SPIRE Graduates to CNCF Incubator

This item in japanese

The Cloud Native Computing Foundation has accepted SPIFFE and SPIRE as incubation level projects. SPIFFE defines a standard to authenticate software services through the use of platform-agnostic, cryptographic identities. SPIRE is an implementation of the SPIFFE APIs that is production ready.

The SPIFFE (Secure Production Identity Framework for Everyone) specification is designed to work within dynamic and heterogeneous environments providing a means to mutually authenticate workloads. At the base of the specification is the concept of short lived cryptographic identity docs, known as SVIDs (SPIFFE Verifiable Identity Documents), available via API. Workloads can leverage these documents to authenticate to other workloads.

SPIFFE has support for workloads within AWS, GCP, Azure, and running on bare metal. There are also integrations available with Kubernetes, Docker, Vault, MySQL, and Envoy. A number of projects are now issuing IDs as per the SPIFFE specification such as Istio Citadel, Consul, and Kuma.

The CNCF Special Interest Group for Security (SIG-Security) conducted a security assessment of SPIFFE and SPIRE. There were no critical issues found and they commended the team on the security-focused design.

Within the SPIFFE framework, a workload is a piece of software deployed in a particular state for a single purpose. It is possible for this to be anything from a physical or virtual node to an individual running process. SPIFFE assumes that each workload is sufficiently isolated such that a malicious workload is unable to steal the credentials of another workload.

Each workload is assigned a SPIFFE ID which identifies it uniquely within a given trust domain. This ID is a URI of the form spiffe://trust domain/workload identifier. For example, spiffe:// would be a valid SPIFFE ID.

The trust domain corresponds to the trust root of the system corresponding to a distinct of the SPIFFE infrastructure. All workloads that are present in the same trust domain are issued identity documents that can be verified against the root keys of the trust domain. It is advised that workloads that are in different locations or in environments with different security practices (such as test versus production) are kept in distinct trust domains.

Workloads are able to prove their identity to a resource using the SPIFFE Verifiable Identity Document (SVID). The SVID is considered valid if it is signed by an authority within the SPIFFE ID's trust domain. Within the SVID is a single SPIFFE ID representing the identity of the service presenting it. This is encoded as either a X.509 certificate or a JWT. It is recommended to use X.509 where possible, as tokens can be susceptible to replay attacks. However, in cases where an L7 proxy or load balancer is between workloads, the JWT approach may be the only option.

SPIFFE also provides a workload API for obtaining the identity documents. For X.509 formatted documents, the API will return the SPIFFE ID, the private key tied to that ID that can be used to sign data on behalf of the workload, a corresponding, short-lived X.509 certificate, and a set of certificates (known as a trust bundle) that the workload can use to verify X.509-SVID's presented by other workloads within the trust domain.

Similar to how the AWS EC2 metadata server API and the Google GCE Instance Metadata API are structured, the workload API does not require that the calling workload have any knowledge of its own identity or have a valid auth token to initiate the call. This allows for applications to not need to be co-deployed with secrets for their workloads. To minimize the risk from a compromised key, all private keys and corresponding certificates are short lived and rotated frequently and automatically, with the option to force a rotation if needed.

There is a Go client library available that provides an interface to the SPIFFE workload API. Additionally, the SPIFFE Helper utility can be used when integrating with applications that cannot write to the workload API directly. Finally the SPIRE agent binary can be run as a client of the workload API and provides some utilities for retrieving credentials.

SPIFFE and SPIRE are available for download from GitHub under the Apace-2.0 license. With this announcement, SPIFFE and SPIRE join other incubation-level projects such as gRPC, NATS, and Falco.

Rate this Article