 Okay, we're nearly there. Thanks for sticking around everyone. I am going to be talking in five minutes about Istio and Spire and how we can do cross-domain trust in hybrid cloud environments. That's a bit of a mouthful. I mean that title's nearly five minutes long, but hopefully you'll see what I'm getting at with a lot of the cross-domain sort of trust federation that have been touched upon in a lot of the earlier talks. Actually, this is going to recap a little bit of the Bloomberg talk and of Zach's talk, but hopefully we can really reiterate the one important message that Spire is a really useful tool when you start to scale beyond just the one Istio mesh and you want to enforce global policy and do all that kind of stuff. So I'm Matt Turner. I'm a software engineer at Tetrate. Also, many thanks to the folks over at Control Plane. Could they help me with a bunch of details when I was preparing this talk? So I think we all know that the mesh uses Spiffy to get its workload IDs. I mean, what actually is Spiffy? It's not an implementation, it's a set of specs. It uses specs for workload identity formats, for workload identity documents, this Svid, this Spiffy verifiable identity document, and it gives an API for workloads to go and exchange some kind of attestations, some kind of proof of who they are for one of those Svids. I should just quickly say that Istio doesn't actually implement all of the Spiffy stuff. It doesn't implement the workload API, for example, but it does use the Svids document format and it has its own subset, its own opinion of that Spiffy naming format. So in Istio, it's going to look something a little bit like this, that that Svids is implementation agnostic and actually can be embedded in a bunch of different formats like a Jot, but Istio uses it as an X509 certificate. So we can use this to do our authentication and therefore authorization, but that, as Zack said, has the nice side effect that we can also use it to set up encryption on the wire to do a mutual TLS handshake and get an encrypted tunnel. So in the mesh, it looks something like this. An Envoy sidecar is going to need a cert. Envoy fetches that over its secret discovery service protocol, actually fetches it from the local Istio agent over a Unix domain socket. Istio agent will go and get that from Istio D. Normally, if you just got the one mesh, if you just do a default Istio install, those certs are going to be signed by a CA and that CA is just one that Istio D when it starts up and self-signs. And this is absolutely fine. If you're a trust domain, your identity domain is just the mesh that you've got. Things get a little more complicated when we're talking about multiple meshes. So a kind of multi-region setup or a hybrid cloud setup, which is a place I know a lot of folks are, or any of the other reasons that we all see people running 2,000 Kubernetes clusters because they feel like it. So we can share a trust domain between these meshes so that workloads can trust each other across the meshes. And we can do that by manually providing each with a root cert. And a classic way to do that would be that they themselves are intermediates signed by a common route. So this route can be another self-signed cert that you make. It could be part of a larger corporate API hierarchy. Or if you're in a private cloud, it could be a key cert pair from the cloud management, so the key management service in the cloud. But what, for example, if we want to establish trust with a partner, what if we're not prepared to have one Uber key that can sign everything? We don't want to take on the key management burden of that. So this is where Spire comes in useful. So Spire is the reference implementation of Spiffy. They have an agent. They have a server. They implement all the different parts of the system that the Spiffy specs talk about. So we can change our routes of trust out to be Spire. So a separate Spire server for each mesh. And then we get some kind of co-options. The first of which is that we can federate trust between the Spire. So the Spire server is a route of trust. There's ultimately a CA in there, like a trust bundle. And one of the things that Spire is designed for, can do first class, is to sort of federate trust between these trust bundles. Nothing you can't do by cross-signing your own CA's, but Spire is kind of designed for this and makes it really easy. So if we do this, we get S-vids that are trusted in both universes. So this is the foundation for a kind of zero trust architecture that's going to span this hybrid cloud setup, or this multi-region setup, or whatever it is. So this does let us set up encryption on the wire. That is proper end-to-end, you know, envoy-to-onvoy, sidecar-to-sidecar encryption on the wire because as Zach mentioned in his talk, we can SNI route those things between transit gateways. We don't have to terminate the TLS at the ingress or the egress at any of these clusters. We can SNI route it and get proper end-to-end mutual TLS. And then using that authentication, we can do authorization, so we can enforce policy globally, right, no matter what cloud you're in or no matter what compute infrastructure you're on. So to the point earlier, if you want to do, you know, identity-based policy, identity-based access control, you're limited by your identity main, by the size of your identity main. So if we can bridge it, if we can extend it, then we can have that universal policy and with Spire set up like this, one Spire server per cluster, we don't have to give up control of our key material to do it. And Spire can also do some cool stuff on top, like we can trust only in one direction or we can trust a subset of the identities in the other federated domain or that kind of stuff. Just a very quick aside, just on five minutes for the curious or the nerdy, this is how it actually works if you want to go set this up. It's not quite as simple as switching out a CA, so if you want to use Spire, you add a bunch of stuff to your Istio operator resource, this injects Spire's agent into the side car alongside Envoy and the Istio agent, and then it's hands-free, then it's all transparent. So when the Istio agent starts up, it actually detects the presence of the Spire agent by just seeing its default Unix domain socket path and it'll forward SDS requests, so Istio agent, rather than talking, sending a CSR off to Istio D, will forward the SDS request to the Spire agent, which will then talk the actual workload API despite in Spiffy off to your Spire server. And like Istio D, what the Spire server is actually going to do is check that SS station, check that workload identity by taking the service account token of the service account that this pod's running under and handing it to Kubernetes. So that's the same as Istio D does, so you're verifying the same identities, but you're lifting it into this unified trust domain based on the Spiffy standard. And in five minutes, that's kind of all I wanted to say. So thanks very much for your time. See you around.