 I'm Glaus Maraghiar and first of all, it is a pleasure to be here and present this project today. Me and my colleague, Dan Feldman, will talk about the work to connect Istio Service Mesh and Despire and at the end, we will demo our progress so far. So hope you like it and have some fun! In case you didn't know, Istio is a service mesh for Kubernetes. It means it adds a sidecar proxy alongside each service in your Kubernetes cluster in order to enable advanced networking features like API gateways, load balancing, and mutual TLS encryption between services. For that mutual TLS encryption, Istio has always used SPIFI certificates, but Istio doesn't have a lot of the advanced features of Spire, like attestation, a workload API, SPIFI jots, and SPIFI federation. On the other hand, everyone is using Istio. Its adoption is really widespread in the cloud-native community. We don't want to have to force people to choose between using Istio and using Spire. Instead, we want them to work together really well, and that's the purpose of this project. Before we started this project, we embarked on a number of different, easier approaches that didn't involve modifying Istio in order to make Istio and Spire more compatible. The first approach was tricking Istio into using Spire certificates by essentially hijacking the traffic to the Istio certificate authority. This actually worked in early versions of Istio because those certificate requests to the Istio Citadel certificate authority weren't validated in any way. You could actually just put some proxy in the way that would intercept the certificate request and put in a Spire certificate instead. But that hasn't worked in Istio for over a year now because, finally, those Istio certificate requests are actually encrypted and validated. Next, we tried using the same upstream CA, both for Istio and for Spire. This gets you some level of compatibility because then you can have some outside services that use Spire certificates and some inside services that use Istio certificates, and then because they're both Spifi certificates, they have some level of compatibility with each other, but you still don't get all the advanced Spire features like attestation and the workload API. Next, we tried using an Envoy sidecar, a second Envoy sidecar running inside Istio that translated Istio certificates to Spire certificates. This basically doubles the overhead of doing mutual TLS encryption because you have an Envoy proxy that decrypts the Istio encrypted traffic and then re-encrypts it with Spire encrypted traffic. This works. It's a hack and we wouldn't recommend anyone use it in production, but it does get you to achieving part of the goal. And then, finally, we also attempted to reconfigure the Envoy configs that Istio generates to read Spire certificates instead. And again, this does work. It causes some problems with communication with Istio daemon and with Istio gateways, and also it's a hack that probably no one would run in production. So what we really needed after trying all these approaches was a modified version of Istio that knows how to talk to Spire itself and get Spire certificates. So our goal for this project is to modify Istio itself to optionally use Spire certificates instead of Istio certificates. So there are no changes to Spire as part of this project, and there are some minimal changes to Istio in order to talk to Spire. So we started by developing a proposal and sharing it with Istio community, gathering feedback from the Istio community. And then once we're complete, once we have this work 100% and tested and documented, we are planning to work with Istio community to get it into upstream Istio. What does integrating Spire with Istio really buy us? First of all, and most importantly, it gets you at a station based on hardware or cloud identity. Istio doesn't have this by default, but with Spire and Istio working together, every node that's added to the Istio cluster, every workload that's running on that node can be attested down to its hardware identity using TPM or its cloud identity using instance metadata. Next, this will help with integrating with noncluster workloads. So if you have a service that's running completely outside Kubernetes or just outside Istio, but still inside Kubernetes, it can get Spire certificates straight from Spire. And then workloads running inside Istio, which are getting Spire certificates through the modified version of Istio, then they can talk to each other. Next, you get easy federation from the Istio Spire instance to outside Spire instances or other OIDC federation. Maybe you can federate with an OIDC endpoint in order to access cloud APIs natively. So that's really helpful. Another security feature is that because Spire allows you to keep your root keys outside the cluster and also automatically rotate them frequently, it's a little bit more secure. Istio by default generates the root keys locally and keeps them inside the cluster and then it really never rotates them. So with Spire, you can keep all that key material outside the cluster. And then finally, workloads can access the workload API, which means they can get other certificates, not just the Istio certificates, but maybe some other certificate that you want to assign them, maybe some trust bundles, maybe some Jots, other things that the workload API could provide in the future. And Istio workloads would be able to access that directly. In summary, what we're doing as part of this project is replacing Istio's internal certificate authority with a new integration path that allows connecting Istio to external certificate authorities. And then we have Glue Code that allows connecting Spire to this new certificate authority API. You no longer need to use the Stiffy workload API at all because all the incoming and outgoing traffic will go through the Istio proxy, which will automatically use the workload API under the hood and be able to access all the Spire certificates. But you still can use the workload API if you want. And this is a big advantage because mounting that workload API socket path can be challenging in certain situations where you have limited permissions on the Kubernetes cluster. And finally, there's a whole team working on this at HPE and not just us. And HPE is committed to developing this new feature and getting it upstream and Istio as soon as we can. Thanks Dan. Let me go a little deeper here. In this diagram, we see a representation of the main components, APIs, and protocols in use within Istio self-smash ecosystem for communication and identity distribution. And void, the sidecar used within Istio service mesh, as Dan mentioned, communicates with each other using MTLS. Istio agent communicates with Istio D in the control plane for fetching identity for itself and for the sidecars. It does that using a CSR API. And this is not a good fit for Spire or workload API. So because of that, the path we decided to take was to teach Istio D and Istio agent how to fetch identity from Spire agent. To do so, we implemented a configuration that allows Istio to fetch identities from an implementation of this FeeFee workload API in this diagram represented by Spire agent as an alternative to using CSR API to fetch identities from Istio D directly. So we have two options available. And for those of you who may be curious, this was done using an existing interface in Istio called Secret Manager. So the chains are localized, very beautiful and elegant, I would say. And the communication between the sidecars was not changed. MTLS is still in place using Spire issued certificates. In this slide, we can see the fetch identity flow using Istio default configuration and the alternative developed by this project using an implementer of Spiefe workload API represented here by Spire. As you can notice, the change does not affect Envoy and how it integrates with Istio agent. It only affects Istio agent fetching identity and in the default flow, Istio agent generates key and CSR and contacts Istio D using a sign request, which Istio D responds, signing the request, the certificate acting as DCA. On the other side, when Istio is configured to fetch identity from Spire, Istio agent does not communicate with Istio D or nor use the CSR API. It connects to Spire agent using workload API to fetch identities. Although we did not represent it here, Istio D also interfaces with Spire agent for fetching its own identity. And that's the magic explained. Okay, but that's not all, folks. There is more to come. The list of tasks has just started and includes, but it's not limited to, Federation, TBD, which forms a Federation we are talking about, Istio Federation, Spire Federation, both together if it even makes sense. But anyway, custom Spiefe ID supports, for those of you who know Istio, you'll probably remember that it is only happy if Spiefe IDs follow a predefined standard, which has name space and service account identifications. However, if one wants more flexibility or leverage existing Spire issued identities that does not follow Istio standard, they are in trouble. So and last, but certainly not least, we are looking to upstream these chains as then already mentioned before. So enough talk. Let's go to the show. And now it's time for the exciting part of our presentation, the demo of Istio and Spire working together. Today we're going to be showing Istio and Spire, of course, but also Tornyak, which is the user interface for Spire that's under development, and Keali, which is the user interface for Istio that comes with Istio. The application we'll be demonstrating is called Bookinfo, which is the built-in Istio demo app. It consists of a product page written in Python, a reviews page written in Java, a details page written in Ruby, and a rating service that's on the back end written in Node.js. And they all have to talk to each other. There are three instances of the reviews page. So each time you refresh the page, it will actually show a different review. Each service in Istio gets a sidecar proxy. So each one of these will have its own Envoy sidecar proxy. And because we're using Istio Spire rather than regular Istio, each one of these sidecar proxies will be getting its identity from Spire. So yeah, so thank you, Dan. And let me just show you then this environment in which we have the Istio Spire integration running. As Dan mentioned, we have Bookinfo application running as well. This is the main page of the Bookinfo. Oh, before I move on, this is running on AWS and EKS cluster that is stood up for this demonstration. And this is the Bookinfo. So we have the BookDetails. This is the product landing page. And we have the BookReviews here. If I reload the page, we will see change going on in this BookReview piece of the part of the page, which are provided by the three different reviews, workloads and versions that Dan mentioned before. So looking at Keyali dashboard, we can see the traffic going through Istio ingress gateway through the product page, through the other pages and workloads like details, reviews, and ratings. Let's take a look at Torneq, the UI for Istio Spire. Looking this first page here is the Torneq dashboard. We can see that there are some information here like the two agents that are running, one for running on the control plane, and the other one running with the single node. Oh, I forgot to mention this is a two nodes cluster. One for the control plane and the other one for the data plane. And we have the two agents running here, one serving the Istio agent running on the node and the other one serving the Istio D. And we have all of the entries that are registered to Spire. I'm going to move to this other view of the entries, which will be easier for us to identify some of the entries. So we have, let me just scroll down to show you the interesting ones, which are the ones related to the book info application. So we have the one related to the book info details workload, the book info ratings workload, the book info reviews. And we'll have three different entries for the reviews and the one for the product page itself. So that's it. In addition to the other entries that are common for the Spire infrastructure. Thank you very much for attending our talk today. If you have more follow-up questions, please feel free to email either me or Glaucimar. And you can also find us on Spiffy Slack all the time. Thanks. Bye. Thank you.