Re: SPIFFE Presentation - TOC Agenda 11/7/2017
|
Andrew Jessup <andrew@...>
Hi Deepak - great to hear from you! Some answers to your questions inline.
Istio has implemented the X.509-SVID as its identity token. This is part of the SPIFFE specification. We’re working closely with the Istio team (and others) to align on a joint full specification. More on this below. I'd say it's fair to say that Istio is one very powerful application of the principles behind SPIFFE, but not the only one. Both projects aim to solve for identity beyond Kubernetes and are thus conceptually aligned. The near term goal for both projects is to align on a common specification, such that either implementation could form the basis of an Istio implementation. Our long term goal is to merge implementations. SPIRE will remain independent, regardless of whether the long term goal is reached or not. The SPIFFE specifications have been explicitly structured in a manner to support multiple SVID formats in the future. Indeed the "JWT-SVID" is something the SPIFFE community has been investigating. We recognize the limitations and shortcomings of an X.509-based SVID, and seek to address at least a subset of those use cases with the introduction of a JWT-SVID. Namely, we seek to decouple identity from transport. Work in this area is ongoing. Our main motivation to initially support X.509 was that multiple mTLS libraries can support it with little modification, and SVIDs could thus be used to establish mTLS. Many JWT signing and verification libraries also accept X.509 certificates, meaning applications that prefer to use JWT tokens to assert specific claims could, in principle, use X509-SVIDs to do so.
If this topic interest you, we’d love to speak further to learn about your use-case, and how SPIFFE could help. I’d also recommend getting involved in the SPIFFE Specifications SIG which has an active Slack channel. “Yes” is the short answer here :) The longer answer is; the definition of what constitutes a given workload (and thus should be assigned a given identity) will vary between organizations, platforms, and projects and so we support a flexible "attestation policy" framework to allow folks to define identity in a manner that makes sense to them. An attestation policy describes conditions (such as “is member of an AWS instance in a given security group” and/or “has given process ID” and/or “is associated with a given Kubernetes service account”) that SPIRE must verify before issuing an identity. Evan Gillman gave a demo recently of this capability to the k8s SIG-Auth, showing how SPIRE can issue identities based on k8s-speciifc constructs such as namespace or service account. The goal of the SPIRE project, via a range of plug-ins, is to provide a rich and extensible language for this attestation policy that can be used to reliably identify a wide range of workloads in heterogeneous computing environments. Notably, since SPIRE supports attestation based on infrastructure as well as workload, it can be used to issue identities accross different Kubernetes clusters, as well as non-Kubernetes based workloads within the same identity namespace.
As you note, unlike oAuth related protocols (including OIDC), the X509-SVIDs and corresponding private keys don’t need to be issued for each connection, and have a tunable TTL. This has a few tactical advantages, including (a) faster time to establish a connection than if each connection needed to to be negotiated independently with a round trip to a trust broker, and (b) any system that relies upon them to establish connections is more resilient in the event of any transient failures of the SPIRE service. OIDC seems to primarily care about negotiating trust and authorization between two parties where trust has already been established to a third-party (which can act as a broker). This pre-establishment of trust is often using a pre-shared secret, but could be performed in many ways (including via SPIFFE/SPIRE, conceivably). SPIFFE/SPIRE don't reason at all about authorization. While SPIRE does have a client-server architecture, it isn’t designed to be fully decentralized, or to eliminate SPOF (though this can be mitigated by increasing the TTL of the identities issued, and a HA mode is in the works). SPIFFE/SPIRE does expressly support the ability to carve infrastructure into multiple “trust domains” to mitigate the “blast radius” of a faulty or compromised SPIRE control plane. And as noted above, longer lived X509-SVIDs can add resiliency in the event of an outage of SPIRE (at the expense of a wider impact should the key be stolen). Additionally, a fully P2P-based SPIFFE implementation is conceivable here, too, though not on the near-term roadmap. If you see value here, let’s chat!
A likely path here is that if each legacy workload can be identified with a SPIFFE ID by SPIRE, an agent could then map that SPIFFE ID to a legacy token, and then act as an exchange between the two. Some secrets management tools already perform this function to some extent, and we hope to see some of them support SPIFFE directly over time.
Andrew Jessup | Scyale.io | +1 (347) 855 6187 | Let's meet!
|
|
|