 Nice. Some good, good app devs. Do we have app devs here? It's mostly platform. Awesome. Everybody else, there will be really good stuff here too, but today the main audience is the platform folks. What I want for y'all to take from today is really two things. So one, there's a lot of security things that we can do with Istio beyond just the basics. The basics are really useful. MTLS is really powerful. We just had some really awesome talks earlier today throughout the day. It's been a really security filled day, which has been great. Around a lot of what I would consider kind of the basic bread and butter Istio use cases, right? MTLS authorization policies and similar. I'll talk about those and how those are incredibly valuable for a lot of different controls and compliance. But the other thing that I want to do is get into some of the more advanced and kind of interesting use cases that we see. They will actually segue pretty nicely off some of the stuff that the folks from Bloomberg just talked about. The other thing that I would like to do for the platform team specifically is help arm you and help equip you to go and talk with the security part of your organization and with other parts of the org. And really what should happen in the ideal case is that you are going to be the security team's best friend. As a platform group bringing this technology in, you can help make the security team's life a lot easier. And that in turn gives you a lot of leverage to help actually move the platform forward in your organization. So hopefully we're going to get both of those things and I'm going to talk about them in reverse order. So I'm going to start by kind of setting some stage and some context and hopefully build into some things like a pretty tractable definition of a zero trust and some things like that that you can use to then go and talk with the rest of the organization. So a lot of this is going to be reviewed because of the excellent talks before mine. If we start at the simple case that we've already talked about that we're all very familiar with, a user wants to access a service. And I'm not even talking about Istio but just how do we build applications. That user is going to hit some public address that's going to come in through the front door at that front door. Maybe that's an API gateway. Maybe that's an F5. Maybe it's an envoy. Maybe it's an Istio ingress gateway. It doesn't matter in general what we're going to do is look at what came in. We're going to talk to our system of record to authenticate the user. Probably we're going to apply some author, we're going to do something like OIDC like the Bloomberg folks just talked about. We're going to authenticate that user. There's probably going to be some coarse grained authorization that we're going to apply. Can this user call this API endpoint? And then fundamentally we're going to do the job of a reverse proxy we're going to afford to belong. But critically we are doing this authentication of the end user and authorization of the resources that they're allowed to access. One other kind of key idea that I want folks to take away as well is that when we're writing this identity based policy, our policy is limited in scope by the identity domain. A little bit later in some of the lightning talks, we're going to have some talks around things like federation to be able to help facilitate policy that spans further. But one of the key, key ideas that I want people to take away is this idea that as we're moving into out of a network based policy and into identity based policy, the identity domain is going to be your key limiting factor. And it's exactly the same when we move to talk about services. So end user off, we've been doing that bread and butter for forever. So one of the most novel pieces that Istio brought to bear, and one of the reasons it was very interesting for folks, is the fact that we can start to do that for services too. We can issue a strong service identity, a spiffy identity like they talked about before, and we can use that to authenticate our services at runtime and authorize them. And again, because this happens to be an X509, we can also use it for encryption, that's nice. The final piece of the kind of mental model that I want to leave you with before we move on, is the core idea that motivates the Zero Trust architecture. And this is probably what your security teams are having on their plate right now. And the motivation for Zero Trust architecture is that the attacker is already in the network. And so if the attacker is already in the network, what do we do to mitigate the damage that they can do? And we have very compelling reasons to believe that the attacker is in the network. This is a leak from the Snowden files about the NSA's penetration of Google's network. Right? This came out in 2013. We know that the attacker can be in the network if the attacker wants to be. That's why Zero Trust as a model is important today. So if we put all of those pieces together, that end user off, that service identity and off, the need to reduce our perimeter because the attacker is already in the perimeter, what we land at are these five policy checks. I didn't introduce myself at the start. I'm one of the original SEO engineers, but one of the other hats that I wear is working with the National Institute of Standards and Technology in the U.S. to help create the security standards for the U.S. federal government, both microservice security and multi-cloud, as well as Zero Trust. I help write those standards. In an upcoming standard, we will start to talk about identity-based segmentation, which is these five policy checks. These five policy checks should happen at every hop in our system, and the service message is a spectacular way to do this. What we argue in this paper, which will be released next month, if you do these things, you've achieved a Zero Trust runtime. Now, for this group here, especially the platform folks, we can look at that list and go, hey, I think SEO can do like those. Great. This is exactly how we can A, start to achieve some of the basic controls. B, this is how we can start to get leverage to win friends on the security team and create that virtual cycle that helps platform adoption. Some other kind of key ideas that I want to leave you with to talk with the security team. Envoy is a pep, a policy enforcement point. Again, the Bloomberg talk was perfect before mine. OPA is a policy decision point, and exactly in their architecture, they were using Envoy to enforce the policy that was rendered by OPA. That is a perfect example of Envoy as a pep. Of course, we can also do things like an SEO authorization policy. That is another class of policy that we can use Envoy to enforce. In general, think of Envoy as the place to land policy when you're in a service mesh architecture. We argue, and I'll link some later, we argue that this will leave you in a more secure state compared to doing things like including an SDK in your application in some of the NIST papers, and I'll link those shortly. If we want to get really technical on the access control research side, we would call Envoy a reference monitor. Similarly, in that same parlance, we would call the service mesh itself the security kernel. Don't hear operating system kernel. Here, 1970s research that led to the operating system kernel being an idea. There's an idealized access control architecture and model that talks about the security kernel, which is the place where we can focus the security decisions of the system and hopefully audit it, control it closely, and gain assurance because we trust that code base. The Linux kernel is an example of a security kernel. What we argue in SB 800204b and go talk to your security teams about this is that the service mesh forms that security kernel for a modern distributed system. That's the first half there around just prepping to go talk with security folks. Hopefully, there's some more common language that you can have. You can start to talk about some of these controls. Of course, there's a lot of these that we can use, those basic five things, just doing encryption, off-end, off-Z at the service and user level to satisfy quite a lot of requirements. In particular, things like PCI DSS. There's a slew of GDPR requirements. There's a slew of different governments, finance and health requirements. For example, GDPR requires encryption and transit for PII, for HPI, for other sensitive data. Easy to achieve. Service-to-service off-Z is almost universally required in some form. Today, we traditionally implement it with network policy. What we want to argue, and I'll talk about in just a second, is we can start to do that in the mesh and get into a better world. Again, the same thing is with end-user off-Z. This is an industry standard thing. You've got to have it no matter where you're at. But even other things, for example, audit log production is a common requirement for many regulatory regimes. We have seen firsthand that things like the Envoy access logs can satisfy those audit log requirements for very many regulatory regimes. I work predominantly in the U.S. government side there, so forgive me, you audience, for my U.S. FedRAMP thing. But when it comes to, for example, giving software to the federal government in the U.S., there are about 350 controls, or 350 controls or so, that you need to hit for FedRAMP moderates, even more for FedRAMP high. And Istio can substantially solve a huge number of those. More than 10% of them, and 10% of the very meaningful and hard ones, like the encryption and transit, like access control, like audit production, and others. The second thing that now I want to pivot to is to start to talk about maybe a little bit more advanced stuff. So more than just the encryption and transit and Istio Autzi policy and similar, I want to talk about how we can start to layer this stuff with our existing security model to help get agility for our application developers. So first off, what we want to start to push is the idea of multiple layers of policy, and of course this already exists, right? We know that we have cloud ACLs, we know that we have network ACLs, we know we have these things. One, we want to start to name them so we can talk about them specifically. And so in broad terms, there are two types of policy that we've largely talked about today in all the talks today. We've talked about network-oriented policy, right? Things like the firewall rules, the egress rules that are based on IP address that are based on network location. And we've talked extensively about identity tiered policies or identity-based policies as well, which is the bread and butter of what Istio does. What we want to start to do is enable agility for our application developers by relaxing network policy, which tends to be rigid. It tends to be slow to change. Usually when I want to go make that firewall change request, what happens? Well, somebody on the network team goes and they pull up the spreadsheet and they look through the spreadsheet at all the ciders that are in the firewall rule and they look for the note for what service that subnet belongs to and they make a decision based on that to maybe allow my two applications to communicate or not. This is, we've seen one of the biggest reasons that folks, organizations lose out on the agility that cloud is supposed to bring. So, one of the first patterns that, and we stamp this out regularly in highly regulated environments, is leveraging Istio to bridge the boundaries. So, in this after picture, what we do is we have a universe of identity-based policy on the left side. We have a universe of identity-based policy on the right side. Maybe they have the same identity domain and there's a single set of policies. Maybe there's not. That doesn't matter quite so much. We can talk about the Federation use case where they have different sets of policies on both sides later. That's a much more complicated thing. But in general, it shouldn't matter too much. And what we want to do is stamp out a relatively static set of firewall rules that say, look, I have these identity-aware proxies. I have these envoys. They're allowed to communicate. We have our network perimeter controls in place. We make the auditor happy. The auditor goes and looks. There's firewall rules. There's a very small list of firewall rules, hopefully. Deny everything. Allow these things to communicate. And what we can do instead is control who goes over that pipe with identity-based policy. And what we have seen is that in general, we can change identity-based policy much more rapidly than we can change network-based policy because it is easier for a human to read and understand. I don't have to go to the spreadsheets and map CIDR ranges to a team that maybe used that VM six months ago to a service. I can go and look at the service identity. And hopefully that's a meaningful identity that I can use to back into a team that I know about. As a result of the policy being higher level, it is easier to change more rapidly with a higher level of assurance. As a result, when we see folks stamp out these kinds of patterns, they get way more agility without sacrificing security. Just to zoom in here, one of the things that I want you to take away, you can't probably read those in general. It doesn't matter. What I want you to see is that at that top tier at L7 policies, these are policies that can span across while our lower level policies necessarily have to be segmented. It doesn't make sense to do micro segmentation across my two data centers. That's not really a thing. So I have two universes of policies I need to deal with. As long as we have one identity domain, we can have one universe of identity policy. And specifically, the real reason we want to do this is because using this kind of technique, and this is one example, and you can start to imagine many more in a similar vein. Using these, we can start to shift the needle. We can start to augment our policies. We can start to get agility in a way that's non-disruptive to our current compliance. Bringing this kind of stuff in is what is going to help you as a platform team turn the security team into somebody that you avoid because they say no, and to your best friends in the organization who will help you push this platform out because it makes their lives so much easier. With that, I know I finished probably a little bit early here, but we had such wonderful review before in some of the talks that I didn't want to spend as much time. Please, are there questions, comments, concerns? Have at it. Questions for Zach. Could you clarify what you mean by identity domain in the horizontal aspect? Thank you. That's a phenomenal question. What about identity domain if we go back to the very first example of our users? This one is super easy because basically every organization in the world, what do I do? I use Okta. All my users are in Okta, there's one identity domain. When it comes to services, natively Istio is going to be issuing identities based on the Kubernetes service account. Therefore, your identity domain, unless you do some things, is going to be one Kubernetes cluster. One of the tricks that we tend to use is consistent naming conventions across clusters that effectively replicates that identity domain across them. That is then what gets us into a world where you can have that yellow policy across the top that says A can talk to B even though we may have very different network policies underneath. Does that help make that clear? This is, by the way, a case where Spire is particularly interesting. So Istio itself has a fairly simple identity system based on just the Kubernetes service account. Spire supports features like federation, like cross-signing, like trust of a subset of a different organization's accounts, that kind of thing. That is another way in which that identity domain can be expanded. Other questions? Oh no, that's either very good or very bad. Let's have a big round of applause for Zach. Thanks, I think you nailed it. Alright, well we're going to be mixing things up here.