 So hi everyone, my name is Jackie Elliott and I am a software engineer at Microsoft and today I'm going to be talking about some of Istio's supported identity solutions and why or why not these solutions might not work for you or work for you. So what identity solution you choose really depends on who you are. So who you are informs what's important to you, what you're willing to compromise, how you want to balance simplicity, security and stability and how you want to incorporate any existing infrastructure that you're bringing to the table. So can I get a show of hands for who's like relatively new to Istio and they're testing things out? Okay, so a lot of people. Okay, so who here feels like they're really well established with Istio, they have an identity solution that works for them or they're looking to reevaluate it. Okay, okay. And then I'm not going to ask this, I'm sure you're all super curious about this talk so I'm sure I'd see everyone's hands. Okay, so regardless of wherever you're at on your Istio identity journey, what does an identity solution in Istio or a service mesh in general really help you achieve? Well with the help of a service mesh, you can work towards establishing a zero trust environment. This means that between entities in your service mesh, there's no implicit trust. So every component has to prove it is who it says it is. And this principle is well captured in MTLS. This is where both the client and the server both present verified identity documents as a requirement to establishing a secure connection. And even with Istio's like simplest identity configuration, it provides you MTLS by distributing certificates to your workloads. So what are some of the common threads that you'll see throughout the identity solutions that we're reviewing today? Well, there are three common infrastructure components. There's your workloads that have an identity that needs to be verified. You have some trusted authority like a certificate authority that's responsible for issuing verified identity documents. And lastly, there's certificates that can be presented by the workload to establish trust. So I've grouped the solutions that I'm talking about today into two categories. The first is where Istio D is in some way issuing certificates. It's either functioning as the root certificate authority and intermediate CA. And this is when it's either generating a self signed root certificate or the user has brought their own intermediate or root certificate for Istio D to use to issue certificates. And then the second set of solutions is where you're bringing your own certificate authority. Istio D might be involved or the control plane might be involved in some way, but it's not issuing certificates. And this is when either your CA implements the Kubernetes CSR API. You're using the Istio CSR agent provided by cert manager or you're integrating with Spiffy or Spire. So when we're evaluating these identity solutions today, we're going to be looking at the high level architecture and then diving into the configuration necessary for this identity configuration and then why this solution might work for you and why it might not. Okay. So before we get started, I'm going to define some key terms. So these all sound really similar, but they are in fact different. You don't have to remember this throughout your presentation. But to me, when I was practicing, I was realizing these all sounded really, really similar. So I just wanted to clarify. So there's the Istio certificate signing request. This is a protobuf definition that encapsulates the information necessary to request a certificate. And then there's a Kubernetes certificate signing request. This is a Kubernetes native resource that is created to request a certificate be signed. And then there's the Istio CSR project. This is an agent created by cert manager that's responsible for translating Istio CSR request into cert manager resources. So again, you don't have to remember all that, but just remember they're different. Okay. So let's dive into our first solution. So this is when Istio D is functioning as the certificate authority. It creates a self signed certificate on startup and it stores this certificate in a Kubernetes secret called the Istio CA secret. And this is the default configuration method. So if you install Istio and provide no other configuration, this is what you're going to get. So let's step through how you actually, or how your workloads actually go about obtaining their identity or verified identity. Well, first Istio agent creates a certificate signing request, sends that to the control plane. Istio D verifies the identity of that workload. It issues a certificate if it's successfully verified and returns the certificate to the proxy. Envoy makes a request for the workload certificate. And then Istio agent provides that cert and private key to envoy for its configuration. So why might you choose this solution? Well, it's really easy to just get started with and quickly onboard and test Istio in your test environments. And it really doesn't require that you configure your own CA at all, right? Istio D is handling that for you. So you can just test Istio and Istio related things and not worry about bringing your own CA solution. So why might this not work for you? Well, maybe you don't want your root certificate's private key stored on your cluster. So in this solution, if you remember, we created it or Istio created it, Istio CA secrets, Kubernetes secret that contained the root cert's private key. Maybe that's not something you're comfortable with, so this solution might not work for you. Also, this isn't as robust as the other solutions that we're going to be looking at today. And again, by nature, it doesn't provide any integration with your external or custom certificate authority. Okay, so this is our next solution. It's relatively similar to the previous, but in this case, the user creates a Kubernetes secret named CA certs with root or intermediate cert information. So when Istio D is created, it looks for the existence of the secret, so instead of creating its own self-signed cert, it will use this secret instead, or the information or the certificate info in that secret. And it uses that information as its signing certificate. So this is kind of an example of what it looks like. But I want to call out here is that you can provide a, you can specify the intermediate cert here. So Istio D can issue certificates with an intermediate level of trust, so it can kind of function as an intermediate certificate authority. So the secret can take on several different forms, but the main thing that's important is you can provide an intermediate cert, so you can keep your private key of your root CA off of your cluster. So it kind of addresses the problems of the previous example. Okay. So why might you pick this solution? Well, it's a really great balance between letting Istio D handling, let Istio D handle issuing certificates and also somewhat being able to integrate your, maybe existing identity infrastructure. So it's a really great balance by letting Istio D take over some of the work. And it provides this intermediate CA support. So you can keep that private key off of your cluster for your root CA. So why might this solution not work for you? Well, you're not fully integrated with whatever external or custom certificate authority you have. A cluster component that you have, which is Istio D in this case, is still doing signing. And maybe that's not something that's acceptable to you. And then previously, root cert rotation was not supported in this configuration. I believe in v1.20, it might be. So this might not be something, this might not be a concern anymore. But that's something worth considering in previous versions of Istio. And then lastly, the secret must be named CA certs. There's no flexibility on naming of that secret. So if you have some existing workflow that doesn't create a secret named CA certs, you'll have to add some custom logic to translate this to another secret. Okay. This is the first solution where Istio D is not functioning as the certificate authority. So some other external or custom trusted authority is verifying identity and issuing and signing trusted identity documents. So in this case, the CA has to implement the Kubernetes CSR API. And it's user managed. So again, you have to provide this configuration. And then in this example, I'm going to be using a cert manager as the certificate authority. And it's going to be configured by issuers, which represent the actual certificates that sign your actual root certificates or intermediate certificates that are helping you issue your certificates. Okay. So how do you go about obtaining identity? Well, Istio agent creates a certificate signing request similar to the previous examples we've seen. It sends this to Istio D. Istio D authenticates the identity of the workload. It creates a Kubernetes CSR resource. And the custom CA authenticates Istio D and signs that Kubernetes resource. Istio D picks up on that certificate that's been added to the status field of that resource and returns the sign certificate to the proxy. Okay. So let's actually extend this example a little bit further. So let's introduce workload B. This workload could either be in another namespace or simply belong to a domain that should be partitioned from workload A. So when you're using a CA that implements Kubernetes CSR with Istio, you can configure it to use different signers for different workloads or namespaces. So by modifying the mesh config and applying Istio proxy configs, you can control which signer is used for which workload. So in this case, proxy config A specifies that workload A's certificates should be signed using cluster issuer A. And then the same goes for workload B. Proxy config B specifies that workload B certificates should be signed using cluster issuer B. So once the proxy configs and the workload A and B's receive their certificates, they will be unable to communicate. Because in this scenario, these cluster issuers are signed by different CA's. So they have different chains of trust. So they're not able to communicate even if they tried. So why might you pick this solution? Well, maybe you already have an existing CA that supports the Kubernetes CSR API. It already implements it. So this would be a natural extension for you. And maybe you want multi-tenancy and partitioning is important to you. This solution might be beneficial to you by enabling you to have different signers per cluster or namespace or proxy. So why might this solution not work for you? Well, maybe your existing identity solution maybe outside of Istio doesn't support Kubernetes CSR. And you don't really want to invest the time to learning more about this resource if it's something you're not familiar with at all. And it also introduces complexity. You're already adopting Istio. It's already complex. And maybe you don't need to learn or figure out or find a CA that implements this API. And lastly, this is an experimental feature that's documented by Istio. So it's still listed as experimental. So if this is something that's really interesting to you and exciting to you and you'd like this to progress to beta, please let us know because that would be helpful feedback. Okay. We'll jump into our next solution. So this is leveraging the Istio CSR project or the provided by cert manager. It implements the Istio CSR API. And it's responsible for translating Istio CSRs into cert manager certificate requests. And in this case, your CA is going to be cert manager. Okay. So how do you go about obtaining workload identity? Well, similar as we saw before, it all starts with the Istio certificate signing request. But in this case, it doesn't send the request to Istio D. You actually provide some configuration beforehand to send the request directly to Istio CSR, which again implements the Istio CSR API. Istio CSR authenticates and authorizes the identity of the workload. And then Istio CSR creates a cert manager certificate request. The CA signs and issues a certificate. The signed cert is then returned to Istio agent. Okay. So why would this solution be appealing to you? Well, maybe you're already using a cert manager. So again, this is just like a natural extension. And maybe the issuer integration options provided by cert manager are appealing to you. Okay. Why would this not be for you? Well, maybe you're not using cert manager. You don't want to learn how certificate requests or certificate resources work. You don't want to adopt this workflow into your system. And also, you would become reliant on this Istio CSR agent, which has more limited active development recently. Okay. So the next integration I'm going to be digging into is the spiffy spire integration. So I'm not going to go into too much depth here. I believe there's actually a talk later that I'm talking about spire integration specifically with multicluster. And there's numerous other blogs and talks that really dig into how this solution works. So I'm going to keep this high level so that you can understand the pros and cons of this solution. But please go check out those talks if you're interested in learning more about this spire integration with Istio. So first, spire defines a set of open source standards for securely identifying entities in complex heterogeneous environments. And spire is a complete implementation of the spiffy spec that can perform node and workload attestation to securely issue verified identities. And if you're not really familiar with spire, attestation can really just be thought of as verification. So at a high level, spire is functioning as the certificate authority. And typically Istio workload identity verification relies on the Kubernetes API, which can kind of function as a main source of truth or single source of truth. So spire takes this a step further and provides various attestation plugins that greatly expand how you can verify workload identities beyond Kubernetes service accounts and namespaces, for example. So this, again, I'm skipping steps, but I'm just highlighting some common, the most important components of this. And this is addressing not only how you obtain workload identity, but also how you bootstrap spire. So the first step, workloads are actually registered with the spire server, either manually or automatically. The spire agent then requests those registered workloads that are relevant to that node and sends a certificate signing request for each entry. Then Envoy then sends an SDS request to the spire agent for its identity. Spire agent performs workload attestation to verify that identity. And then it returns the spiffy identity document or a certificate to the workload. So why would this solution be appealing to you? Well, spire provides a variety of attestation plugins that enable it to support identity verification in a variety of platforms. And by the same reasoning, the flexibility of spire makes it a great solution for multi-cluster environments. It can easily federate identities across multiple clusters. And it also provides support for intermediate and workload-cert rotation. And then why not? Why would this be too much for you or why is this not the solution for you? Well, maybe you have an existing identity solution that's not really compatible with spire or you're not really willing to move over to using this new kind of attestation model. And if you're already unfamiliar with spiffy and spire and onboarding costs, the future support costs, and complexity are more than you're willing to take on at this moment, maybe this is something you can keep in mind, but maybe put off for the future. So I'm not saying this answer is a forever answer, but it's like, I'll check back in with you later. Let's figure out Istio first. All right. So this is an overview, a broad overview of the solutions that we've covered today. And I've just picked out a few of the pros and cons of each solution. These definitely don't encompass all the pros and cons, but these are just a few that I've picked out. So ultimately, the point of this talk is to help you have more questions about what Istio Identity configurations can do for you. So I want you to have more questions. But I want you to also have the basic knowledge to begin evaluating these solutions. And ultimately, you need to pick a solution that works for you and where you're at in your identity journey. It's okay if you don't pick the most complex or even the most secure solution. You need to pick where you're at so you can provide a great solution for your customers that you're able to support. And then regardless of the solution you pick, you're well on your way to creating a more secure environment that's powered by Istio. So thank you. And I loved your feedback. So here's the QR code to leave feedback. And then I'll leave that up for a second. And also, I'll show the QR code for the Istio user feedback.