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
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.
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:
We will be hearing from the Istio and SPIFFE projects, along with getting a brief update from the Serverless WG.
Chris Aniszczyk (@cra) | +1-512-961-6719