 So what we wanted to spend, like Andreas mentioned a bit as well, there are a lot of work being done by the community, by the maintainers to integrate Spiffy and Spire between the broader ecosystem. So I'll provide a quick recap on that. In addition, we have some interesting work being done by a few community members that they'll be sharing and giving an update around that as well. So first of all, Spiffy and Spire, I think the team has been really busy since the last KubeCon. We have added various integrations. We already are integrated with popular cloud platforms, bare metal, different service mesh, and other open source software. So you can check these integrations out on the GitHub URL mentioned there. But again, this is the integration that we know. We have a growing community of contributors who are doing integrations, doing contributions all the time. We don't really know about them until they get included in the upstream as well. So if you have any of the integrations in mind, if you want to contribute to any integrations, if you're looking to integrate Spiffy and Spire with anything else, do reach out to us. So some of the new stuff that has been recent, a lot, we have seen a lot of service mesh have started to use Spiffy and Spire, network service mesh, which is a CNCR project focused on delivering hybrid multi-cloud IP service mesh. I think are tightly integrated with Spiffy and Spire. Frederick, who is one of the maintainers of the project, will also be doing a session later on on his integration story within his organization as well. We also have Nginx recently introduced a service mesh, and the solution is integrated with Spiffy and Spire as this core identity control plane. Fessel will be mentioning that a bit in his CRD session later on as well. Open service mesh is another upcoming open source project. It's a lightweight, sensible cloud native service mesh. They are definitely plans there to integrate with Spiffy and Spire as well. Dapper, a relatively new event-driven programming model driven by the Microsoft team, I believe. They recently had a new release and the Dapper workload certificates are now Spiffy-SWID compliant and carry a strong Spiffy identity for each workload. In addition, we have a mystery from GitHub, which is a bridge between service proxy. Spiffy is applied there to apply Authent and Autsy policies within that tool as well. We also have an integration pretty much done between another open source project, Parsec. I won't talk too much on that because Paul from that project would be talking in a bit. As I mentioned before, the next upcoming talks are by community members who have done some interesting work with Spiffy and Spire. With that, I'll ask Doran from IBM to unmute. Hey, Doran. Hi. Can you hear me? Yeah, I can hear you. Excellent. Okay. Shall I begin? Yep. Go for it. Tell us about the interesting stuff you've been doing with Spire. Right. Can you move back to the previous slide in just a second? Yeah. Okay. So I thought that my email should be there. Okay. Never mind. You can move to the next slide. Okay. The last slide, Doran. Apologies about that. We left your contact information on your finishing slide, not on the first. Just for consistency with everyone else. No problem. Okay. So my name is Doran Han. I work at the IBM Hi-Fi Research Labs in Israel. And thank you for attending my short talk. I work on an open source project called the mesh for data that enforces data access governance policies in a service mesh. And the link should have been on the slide, but it is not. Anyway, so I'm going to describe proof of concept work that we carried out a few months ago in which we tried to replace the Istio identity issuing mechanism with that of Spire. So for those of you unfamiliar with Istio, Istio is an open source service mesh project. Now, okay. Istio already issues PFI identities. And this slide should have shown us what they look like. But anyway, they're based on namespaces and service accounts. So Istio issues identity solely based on namespaces and service accounts. But if you use Spire on the other hand, you can base identities on a wide range of conditions and not just the namespaces and service accounts. So we were particularly interested in determining the identity of a workload based on the container images of all containers running within a pod. In our proof of concept experiment, we use Spire to issue the same Spifi identities that would have been issued by the Istio identity mechanism. So a few words about our motivation. Using Spire allows us to only issue identities after an attestation process has taken place, ensuring that all required conditions are met. Implicitly, this also means that if the conditions are not met, then the workload will not get any identity and would not be able to communicate with any other services. The main use case for using Spire identities is Federation. Federation would allow workloads running within Istio to communicate with workloads in other Istio clusters. It would also allow workloads in Istio to communicate with workloads running outside of Istio in just about any environment. Unfortunately, we did not get around to actually experiment with Federation. A few words about how we replace the Istio mechanism with that of Spire. In Istio, the proxy sidecars receive their identities through a UNIX domain socket that they share with an Istio agent running in the same container. Most of our work involves changing Istio configuration so that identities would be received from a different UNIX domain socket, that of the Spire node agent. We also had to make some minor changes to the Spire code so that Spire would support the proxy sidecar configuration, which is automatically generated by Istio. These changes were approved and merged into the Spire repository. Next slide, please. Thanks. Finally, if you are interested in this work, you have here a link to our repository. It explains how to recreate our experiment step by step. We welcome contributions. Below it, you can find a link to a blog that we wrote explaining in greater detail our motivation for this work. That's it. Thank you for your attention. Great. Thank you so much, Doran. If you can hang it on for a few minutes. If you have any questions for Doran, please feel free to put them in the chat window. There's the option of interacting with Doran on the Kiko chat feature as well, which was the browser that you used to get into the Zoom chat. Up next. Amir, real quick. Do you mind going back to slides? I think your update just reflected on what had been missing from Doran's slide. Just one of the people to part with. Yeah, I have to stop and present again. Yeah, Doran, apologies about that. No problem. I think there was a URL here. That is the schema that Istio follows as the naming convention. Right? Right. That's the point you wanted to illustrate. Any particular, you want to redirect your attention about like water, the sharp edges or trade-offs here, perhaps like you need to have parsing and everything else. Expect that if you're the time you're doing Federation, things would need to look pretty much the same in other service meshes. Correct? Right. So in order not to break things, we used the same schema as Istio. So that did not change, but the mechanism of giving the identities is now totally different. So we can use all the spire selectors in order to determine what conditions need to occur in order for an identity to be given. This is as long as you stay within the Istio framework. If you are trying to federate with other environments, then you can use different schemas. Right. And recent about it more as a syntax than perhaps encoding too much semantics in the structure of the string. Right? Great. Thank you very much. We're very excited about this integration and thanks again for leading the charge and showcasing how Istio can integrate with spire. Thank you. Great. Thank you so much, Arun. Up next we have Andrew Jessup. He's going to talk about another popular topic, transitive identity. Andrew, you're on. Hi, everyone. Quick sound check. Can everybody hear me? Yep. Perfect. Beautiful. Hopefully my internet holds out. Apologies if it doesn't. So I know we've only got a couple of minutes together. Good morning. Good afternoon. Good evening, wherever you are. Thanks for joining. We're going to spend a couple of minutes on this topic of transitive identity. Firstly, wanted to recap what transitive identity is. And I tried last night at about midnight to come up with a sort of concrete pithy definition. I'm not sure I succeeded, but let's try anyway. What transitive identity is about adding additional authentication context to a receiving workload. So that in addition to being able to verify the identity of my proximal immediate caller, I can also bring into my authentication and authorization decision additional authentication context about upstream parties that might have been involved in an interaction. Perhaps an easier way of explaining this might be to look at some actual use cases. So a common one here is delegated authentication. So as an example, on the left-hand side here, we've got a user, Michelle, she logs into a web application. Let's say that web application is maybe like a mail client. And the web application then, which is authenticated, Michelle, is now going to talk over a private API to a back-end system in order to retrieve Michelle's mail. So in this scenario, the web application needs to authenticate to the back-end. And hopefully they're using Spiffy in order to perform that authentication. So the back-end now knows and can prove who the web app is. But doesn't know who Michelle is and doesn't have any proof that the web application has actually interacted with Michelle and is entitled to retrieve the mail records on Michelle's behalf. It effectively just has to trust that the web app is entitled to do that. And in some simple cases, that's probably okay. But in more complex scenarios, particularly when you have multiple call chains of microservices where you've got organizations running shared services where they don't necessarily trust the upstream party completely and they want to provide additional guarantees. It would be nice if the back-end, the team running the back-end infrastructure was able to verify not only that the web app was the party calling them, but also that Michelle had authorized the retreat, it was that the web app had a valid authentication context from Michelle and maybe even a valid authorization context as well to retrieve email. This sort of scenario plays out in a lot of organizations where microservice development becomes more mature and embeds itself into a more disparate organization. Another use case that's similar but is quite interesting one is when you have a long-running task that a user has initiated. So by a long running task, that might be say a render job, it might be a CICD job. But in any case, really, where as a user, again, I've got an interactive with some system and that system is spinning off a job on my behalf. Let's say it's a CICD job. That job is going to run for potentially a long time. It may run asynchronously or it might even start after I've left my machine and gone to bed. In other words, I'm not in front of a console anymore to be able to authenticate as this particular task. So what we need is a way for this, on the right-hand side here, this task to be able to represent itself as Michelle, as the user who's logged in, and at least be able to represent itself to a subset of the entitlements of Michelle. So this is another case where some idea of transitive identity would be useful here. It would be fantastic if the task was able to present not only its own identity as a workload, but also Michelle's identity or a proxy for Michelle's identity, or for that matter, the scheduler's identity as well, to a resource in order to be able, for the resource, to be able to make that kind of authorization decision. And there's a few variations of these kinds of use cases as well. It's a complex and fairly challenging problem, it turns out. And one that Spiffy today doesn't really solve. Again, Spiffy is really all about the immediate proximal identity of a caller. So the backend authenticating the web app or the resource authenticating the task, but not the broader context that these things are operating in. So we sort of fixed this, if we skip to the next slide, or to address this, beautiful. At the end of last year, actually, we set up a working group called the Transitive Identity Working Group. I forgot to put the link on there, but if you browse around our Slack channels, we'd be happy to point you in the right direction if you're interested in joining this working group and participating in this process. But we set up a working group to explore this problem. And we started that working group by soliciting some real-world case studies. So we had some colleagues from folks like Bloomberg and Adaptance and Netflix, you know, all took their time out to walk through how they were, would like to, or either were employing Transitive Identity in the real world. And those grounded real-world use cases turned out to be really important because when it comes to a topic like Transitive Identity, there's a lot of trade-off decisions you can make between complexity and ease of implementation and robustness and security. And seeing how people had solved for those problems in a grounded real-world setting helps us make some of those design decisions. So we went through that. We also went through and reviewed a lot of prior art. There's, you know, for those who are familiar with specifications like OAuth2 or WS Trust for the older folks on the call, or for that matter, you know, more interesting kind of delegated grant proposals like Google Macaroons. And for that matter, Istio even flirted with this. There was a thing called the Istio RC token. There's been a lot of, there's been many attempts to try and solve this problem in the past. And we spent some time reviewing some of that prior art as well for two reasons. One is we don't want to reinvent the wheel if there are already great standards to solve for this. Let's let the community, or let's figure out how to integrate with and support those standards rather than reinvent the wheel. And secondly, as well, to make sure that to the extent that there have been standards that are proposed that hadn't really seen adoption in market, what can we learn from that? What can we do to make sure that we're not repeating those same mistakes? So we went through and reviewed that and we came up with, you know, first of all, a set of design principles that we wanted to assert. You know, a set of kind of grounded principles for what, you know, SPIFI's implementation or at least initial implementation of Transitive Identity should be. We actually carved out a subset of that problem we call Delegated Authentication. And we put our heads together and put together a proposal. This proposal is still very much a work in progress. It's had some, you know, real-world grant, you know, it's had some initial review from the working group team. What we're now doing is bringing this to SPIFI itself and seeing, because the proposal as it stands implies some extensions to the SPIFI spec, in particular a new token format called the DAS for providing delegated asserted claims. We're now putting that in front of SIG spec and we're starting that discussion. It's been a really useful and robust discussion so far. It turns out the problems that we're trying to solve to solve the Transitive Identity are also problems that people are having in other contexts too, where they want to be able to propagate contexts across calls. So we're starting to get into the meat of that discussion now. And, you know, our hope is that, you know, with the help of SIG spec and the help of the broader community, we'll get to a point pretty soon where we'll have a concrete proposal that we can effectively ratify. The other thing we're doing as part of this is POCing this environment as well. And, you know, actually actually standing this stuff up inspire and making sure that it works. So yeah. And so that's all I've got. If you want to check out the design doc, I encourage people to do so. I also encourage folks to jump on the Transitive Identity Working Group and or join SIG spec if you're interested in that too. And you can find the design doc at the link at the bottom there. And with that, I'll hand over back to Amir. AJ, a quick question from Tat Taylor. Why delegated authentication as opposed to delegated authorization? Sure. Great question. So delegated, so we've tried with Spiffy in general to disaggregate authentication and authorization as much as possible. And the reason for that is it's generally easier to provide to build a general purpose authentication framework that supports a whole set of different use cases than it is to provide authentication and authorization in the same form in the way that say OAuth2 does. To the greatest extent possible, we've tried to do that with delegated authentication as well. There's actually some open discussion right now as to whether or not that should be delegated authorization because how useful is just an authentication claim without entitlements associated with that. So to paraphrase my own answer, I'd say we started from a position of trying to do the simplest, most practical thing that we can. We're starting to hit the limits of that. And so we are starting to explore delegated authorization as well in some form, at least having kind of concrete bounded claims that can be passed around that may capture some authorization decision as well as some authentication decision. Would really encourage you to jump in the dark and or jump in the conversation there to add your voice there too because we'd love to hear from your experience. Great. Thank you so much, Ajay. I know we oppressed for time. Apologize. We're going to run into the break a bit, but I do have a couple more speakers. Up next, as Augustine mentioned about certificate transparency is a big topic within the Spire community. And we have Reed Zhang from Bitense. He's going to walk us through his proposal. Yes. Can you hear me? Yeah, perfect. Great. And thank you for introduction and thank you for inviting me. And I'm Reed Zhang and you can also call me Reed. So I currently work at Bitense and we are known for the creator of TikTok. So here I bet Bitense we heavily integrate with Spire to implement our identity management system for our production network. And during that we noticed that in the current Spire there is actually no very good way to perform auditing on the issued SVs. Like for those who are new to Spire, SV is basically the ID card for an entity in the network. So in this work we try to provide auditability to Spire. We leverage a well-known technology called certificate transparency or CT. And CT was first proposed to enforce public auditing on certificate authorities for WebPKI. And in our case we applied the essential ideas of CT to Spire so that we could enforce auditing on all of the SVs issued by the Spire server. And this way it can significantly mitigate the risk of Spire server getting compromised or having its identity stolen. Without CT malicious SVs could be introduced into the production network without any notice. And so here we will first briefly walk through the original workflow of Spire server issuing SVs. And then we will look at the new workflow with CT edit. So in the original case the Spire agent or workload would first send a request to the Spire server and ask for an SV. And the Spire server would perform validation and logging off the request and then it will issue an SV back. So and this finished the original workflow of issuance of SV. And the case is slightly different for the like for the case with CT edit. So could you click. So in the CT case the old SV would not be trusted. The old SV needs an additional field called SCT in order to be trusted. The Spire server would need to fetch this SCT by logging the SV on CT log. This SCT is short for signed certificate timestamp. It presents that SV to be issued would be added to the CT log within some time. And Spire server would embed this SCT to all the SV issues. And now only the new SVs with SCT embedded would be trusted. And this SCT guarantees the enforcement of auditing through a crypto way, cryptographic way. And could you click. And with that now any interested internal or external auditor can request to the CT log for auditing of all issued SVs. So here in Bydance we would have an internal process keep batching from the CT log and look for suspicious SVs. And this sums up the overview of like the new version of Spire with CT integrated. And in this slide we show an example of issued X549 XP with SCT embedded. The yellow highlighted parts are the SCT field and our newer version of OpenSSL should be able to parse SCT field in the X549 certificate. This certificate is generated by our experimental fork of Spire server. And our current fork all SVs would have SCT embedded. And these SCTs are actually fetched from our own internal CT service here at Bydance. And that's why I want to share. And Umer can go back like can go to the dock link you sent me because like I updated the github link and also the design dock link on that version. But can you put in here? I'll put it in the chat window for sure. Yeah, sure. And yeah, and I think we started the working group three months ago and there have been some like back and forth discussing. And we are also discussing on the on the Github RFC issue. So you are most welcome to check that out. And yeah, and shout out to the great of great work this PV community has been working on. And thank you for inviting me. And that's it for me. Thanks for it. Thank you. Awesome. Thank you so much. I know we are a bit over. So last but not the least, we have Paul Howard from ARM talking about our second SPIFI. Call you around. Hi, can you hear me? Perfect. Yep. Cool. Paul. Sorry. What's that? What's that drawing on that turtle shell in this slide? I see a little parsic Easter egg in there. Oh, wow. That's fantastic. I can't claim credit for the for the handiwork. That's cool. In the thumbnails, I didn't spot that detail. Yeah, thanks to whoever parseced up the turtle. That's awesome. So thanks, and thanks for the opportunity to join this session and quickly talk about the work we're doing with SPIFI, Inspire and Parsec. So just to quickly introduce myself, I'm Paul Howard, Solutions Architect with ARM. And I lead an engineering team here at ARM that is contributing into Parsec. Parsec became a CNCF sandbox project just earlier this year. And so what's Parsec? Well, Parsec is the platform abstraction for security. It's providing ways for cloud native applications to access the security facilities of diverse platforms. So for example, it can handle the complexities of storing private keys, interested platform modules or secure elements, and it can give us uniform simplified interfaces to do those things in our preferred programming languages. And this is so that applications can get access to those best available hardware security facilities in a decoupled way. So keeping them fully architecture agnostic and platform agnostic. So that's what Parsec is. Now, the slide here that Ume has put up, so this is showing us how Parsec can make use of SPIFI identities. This is really valuable for us because it allows Parsec to grow beyond just being a platform abstraction for security. By using these reliable application identities, Parsec can support multi-tenancy. So it can isolate these different client applications from one another so that they can share the hardware, but they can't perform operations with each other's keys, for example. So the diagram on screen summarizes how Parsec can do this with SPIFI identities. So it shows this triangular three-way interaction between the application, the Parsec service, and the SPIA service all along the local machine. So the client application links to a Parsec client library. That Parsec client library can obtain the application's SPIFI ID from the local workload endpoint, which, of course, it can then pass as a job token in a North Header over to the Parsec service, where finally the Parsec service can validate the token back with the original workload end point. So Parsec knows, but by this three-way circuit, that each API call it receives is coming from a client workload with a proven identity. And it can then start permitting access to keys on the basis of that identity. And the really great news is that this is an integration that we've largely completed. So it's still work in progress. It's in the process of being upstreamed into Parsec now. We've done a bit of community enrichment around this as well. So there is a Rust SPIFI library, because Parsec is a Rust project. There is a Rust SPIFI Parsec library that already existed in community, but we've done some enrichment on that as part of this work. There's a Lightning talk taking place later today. That's as part of Cloud Native Security Day, where Andres and I show a demo of this in action. It's pretty cool. We take it at 1,000 miles an hour because it's only a Lightning talk. Do look out for that. Maybe catch the recording. And also, if you have questions for me, either about this integration or about Parsec generally, which I've really only given the nearest hint of what it is, really, you can find me on the CNCF and the SPIFI Slack of WorkSpaces. There's also a Parsec channel on the CNCF Slack. You can come and engage with the entire Parsec community as a whole there. And that's it, really. So, yes, let me just say thanks once again and hand back to you, Humair. So thanks very much. Great, Paul. Thank you so much for doing this.