We will be hearing from the Istio and SPIFFE projects, along with getting a brief update from the Serverless WG.

See everyone tomorrow!

Thank you for posting questions Deepak!

 

On Sun, 12 Nov 2017, 20:32 Deepak Vij (A) via cncf-toc, <cncf-toc@...> wrote:

Hi all, this is regarding the recent CNCF TOC meeting last week, specifically related to the SPIFFE presentation during the meeting. I saw most of the presentation but missed some of it at the end. It would be really great if there is recording available for this session which I could view.

 

Now coming back to SPIFFE, I am really interested in finding out more about it. After the TOC meeting, I did some research on it by going through the content on SPIFFE SIG web page and few other related documents. Based on my initial cursory look at it, I have following questions for gentleman who presented SPIFFE during the meeting:

·       Based on my understanding, SPIFFE is a set of specifications and SPIRE is the actual one of the reference implementation for the SPIFFE specs. Based on my initial research, it seems Istio Service Mesh project has its own implementation which is SPIFFE compliant. The fact SPIFFE/SPIRE and Istio are aspiring to be viable CNCF projects, are these two distinct SPIFFE implementations going to merge down the road or is it to do with the fact that domain of Istio service mesh is service-to-service authentication at the intra K8S cluster level versus SPIFFE/SPIRE strives to go beyond intra service-to-service authentication and additionally provide support for external services access as well?

·       Also, I noticed that currently SPIFFE Verifiable Identity Document (SVID) provides support for only X.509 format. Are there plans to provide support for SVID types such as JWT down the road. Or is it by design that only X.509 format is supported because of vulnerabilities of JWT (masquerading, playback attacks etc.) and X.509 is the only viable format which does not have all these vulnerabilities at the present time. Although, I recently saw a proposal in Kubernetes AUTH SIG “Trustworthy Workload JWTs” for addressing all the known issues with JWTs. Provided all the current JWT issues are sorted out (adding nonce to prevent replay attacks etc. etc.), do we see JWT as a viable SVID format type down the road? Also, from backward compatibility perspectives, Kubernetes Service Account Identity is currently JWT token based.

·       Currently in Kubernetes, identity is defined at the Service level, is the intent of SPIFFE to provide more granular identity at the actual workload level (Pods, Containers or possibly native UNIX Process level)? The SPIFFE demo I recently saw includes identity attestation for native Unix process (database running as a process), in addition to K8S Pod.

·       Why not implement OpenID Connect based identity provider within Kubernetes cluster instead of re-inventing the wheel. I am assuming this may be due to well-known JWT vulnerability related issues as mentioned before. Also, external OIDC implementation does have problems related to network round tripping.

·       Also, I noticed that SPIFFE design aspires to be decentralized versus SPOF issues for OpenID Connect type identity providers. Can’t SPOF issue of OIDCs be addressed by implementing redundant or back-up Identity Providers. Although, this does increase the complexity of the overall solution. Based on my understanding SPIFFE design consists of Node (at the Node level) & Server Agents (at the Master API Server level) components. Initially when I saw decentralized design of SPIFFE I thought it was peer-to-peer based trust model approach, there has been lot of research on P2P trust model in the academia but I have not seen that in practice yet.

·       Lastly, how does this all play out in the enterprise SAML based federated identity environment (good old WS-Security, WS-Trust stuff). How are the legacy coarse grained SOA Web Services going to play out in the SPIFFE like environment. The reason I bring all this up is because legacy enterprise SOA based web services are still going to be there as coarse grain services side-by-side with the newer micro-services architecture.

 

I am sure as I understand more about SPIFFE, I will have lot of follow up questions. In the meanwhile, it would be good to get the fog cleared up in my mind based on my initial understanding of all this. But overall, SPIFFE definitely seems to be a step in the right direction and I am really interested in this effort going forward. Look forward to your response on all this. Thanks.

 

Regards,

Deepak Vij   

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, November 06, 2017 12:31 PM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] TOC Agenda 11/7/2017

 

Hey all, we have a TOC meeting tomorrow, here's the agenda deck: https://goo.gl/LoKyV5

 

We will be hearing from the Istio and SPIFFE projects, along with getting a brief update from the Serverless WG.

 

See everyone tomorrow!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

---------- Forwarded message ---------
From: Alexis Richardson via cncf-toc <cncf-toc@...>
Date: Sun, Nov 12, 2017 at 12:52 PM
Subject: Re: [cncf-toc] SPIFFE Presentation - TOC Agenda 11/7/2017
To: Deepak Vij (A) <deepak.vij@...>
Cc: cncf-toc@... <cncf-toc@...>

 

Thank you for posting questions Deepak!

 

On Sun, 12 Nov 2017, 20:32 Deepak Vij (A) via cncf-toc, <cncf-toc@...> wrote:

Hi all, this is regarding the recent CNCF TOC meeting last week, specifically related to the SPIFFE presentation during the meeting. I saw most of the presentation but missed some of it at the end. It would be really great if there is recording available for this session which I could view.

 

Now coming back to SPIFFE, I am really interested in finding out more about it. After the TOC meeting, I did some research on it by going through the content on SPIFFE SIG web page and few other related documents. Based on my initial cursory look at it, I have following questions for gentleman who presented SPIFFE during the meeting:

·       Based on my understanding, SPIFFE is a set of specifications and SPIRE is the actual one of the reference implementation for the SPIFFE specs. Based on my initial research, it seems Istio Service Mesh project has its own implementation which is SPIFFE compliant.

The fact SPIFFE/SPIRE and Istio are aspiring to be viable CNCF projects, are these two distinct SPIFFE implementations going to merge down the road or is it to do with the fact that domain of Istio service mesh is service-to-service authentication at the intra K8S cluster level versus SPIFFE/SPIRE strives to go beyond intra service-to-service authentication and additionally provide support for external services access as well?

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.

·       Also, I noticed that currently SPIFFE Verifiable Identity Document (SVID) provides support for only X.509 format. Are there plans to provide support for SVID types such as JWT down the road. Or is it by design that only X.509 format is supported because of vulnerabilities of JWT (masquerading, playback attacks etc.) and X.509 is the only viable format which does not have all these vulnerabilities at the present time.

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.

Although, I recently saw a proposal in Kubernetes AUTH SIG “Trustworthy Workload JWTs” for addressing all the known issues with JWTs. Provided all the current JWT issues are sorted out (adding nonce to prevent replay attacks etc. etc.), do we see JWT as a viable SVID format type down the road? Also, from backward compatibility perspectives, Kubernetes Service Account Identity is currently JWT token based.

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. 

·       Currently in Kubernetes, identity is defined at the Service level, is the intent of SPIFFE to provide more granular identity at the actual workload level (Pods, Containers or possibly native UNIX Process level)? The SPIFFE demo I recently saw includes identity attestation for native Unix process (database running as a process), in addition to K8S Pod.

“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.

·       Why not implement OpenID Connect based identity provider within Kubernetes cluster instead of re-inventing the wheel. I am assuming this may be due to well-known JWT vulnerability related issues as mentioned before. Also, external OIDC implementation does have problems related to network round tripping.

Beyond this, I’ll confess to having only passing familiarity with OIDC, but from a cursory look at the documentation - to a certain extent, it seems these are solving related but different problems.

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.

·       Also, I noticed that SPIFFE design aspires to be decentralized versus SPOF issues for OpenID Connect type identity providers. Can’t SPOF issue of OIDCs be addressed by implementing redundant or back-up Identity Providers. Although, this does increase the complexity of the overall solution. Based on my understanding SPIFFE design consists of Node (at the Node level) & Server Agents (at the Master API Server level) components. Initially when I saw decentralized design of SPIFFE I thought it was peer-to-peer based trust model approach, there has been lot of research on P2P trust model in the academia but I have not seen that in practice yet.

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!

·       Lastly, how does this all play out in the enterprise SAML based federated identity environment (good old WS-Security, WS-Trust stuff). How are the legacy coarse grained SOA Web Services going to play out in the SPIFFE like environment. The reason I bring all this up is because legacy enterprise SOA based web services are still going to be there as coarse grain services side-by-side with the newer micro-services architecture.

Great question. There are multiple ways to practically solve this problem, but some form of identity and protocol translation is likely necessary to guarantee interoperability. SPIFFE and SPIRE themselves don’t aim to solve for this problem, but should be considered as the foundation for tools that do.

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. 

 

I am sure as I understand more about SPIFFE, I will have lot of follow up questions. In the meanwhile, it would be good to get the fog cleared up in my mind based on my initial understanding of all this. But overall, SPIFFE definitely seems to be a step in the right direction and I am really interested in this effort going forward. Look forward to your response on all this. Thanks.

Always great to hear thoughtful questions about SPIFFE. Hope these answers helped! I’d encourage you to get involved in the SPIFFE community (Slack is a great place to start). Feel free to contact me directly if you’d like some time to go through it.

 

Regards,

Deepak Vij   

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, November 06, 2017 12:31 PM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] TOC Agenda 11/7/2017

 

Hey all, we have a TOC meeting tomorrow, here's the agenda deck: https://goo.gl/LoKyV5

 

We will be hearing from the Istio and SPIFFE projects, along with getting a brief update from the Serverless WG.

 

See everyone tomorrow!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc