 Awesome folks. Thank you, Andrew, for the amazing opening remarks. Next, we have our keynote from Michael Foster. Michael will be talking about crossing the Kubernetes network policy chasm. So let's hear it from Michael. I hope this is working. Hello, hello. Yes, crossing the chasm, building a bridge, whatever analogy you want to use. As he said, I'm Michael Foster. I am the community lead for the Stack Rocks open source project. I'm also a PMM at Red Hat. And I'm looking forward to an exciting week. Very happy, actually, I'm speaking first. Get it out of the way. You're very nice. So let's first talk about why the chasm exists. Network policies today are very efficient at managing pod to pod communication, network rules for namespaces, setting various IP blocks. They're also additive permissions. We default deny everything, and then we add the network policies on top to allow traffic. Now, there is a pretty serious challenge with this process. Because the rules are additive, the communication between the teams tend to break down. The developers need specific rules for their applications. The security teams don't necessarily know that. Maybe the network security team doesn't even know what Kubernetes is. And they're trying to tell you what ports and protocols you can and can't use. And it isn't until the dev test or even staging environments that the developers find this out. So we want to be able to have a solution that can fix the human problem where we can actually leverage the technology that exists today. Because, as they say, Kubernetes network policy is more of a communication challenge with a powerful tool. So what I and the MP guard a project propose is a flexible workflow for the DevSec organizations, a process where the security teams can define a system policy for their Kubernetes clusters and teams, different ports and protocols, what's allowed, what isn't. Where developers, operators, or automated systems can generate Kubernetes policies and validate them against the security team automatically and asynchronously. And then lastly, we want to deploy and test from Git, making updates in our automated pipelines in a way so that the security team updates it, the developers will know exactly what ports and policies have changed. And so the MP guard project was designed with this workflow in mind. Let's take a look. So the MP guard project seeks to simplify the experience of creating and maintaining the K8s network policies. And to help meet this challenge, we want to automate the generation without having to run the application code. So we want to integrate into the applications CI CD pipeline, ensuring network policies gets updated whenever the required cluster connectivity changes. So as you can see up there, first, for the workflow, the automatic synthesis stage, it takes into the applications configuration files, your deployment manifests, your services, things like that. We also want to pair it up with maybe what's the typical traffic that you're seeing. And the security teams can do this all automatically, without the developer being involved. Or if the developer wants to generate them first as well, you can generate and check them in. So the first stage is of the flow also proposes the updated network policy connectivity restrictions in the form of network policy resources. Second, the review and modify stage. So the proposed network connectivity is presented to the DevOps team for the review. This presentation will be graphic, a concise textual report, or simply the actual network policy YAML file. So you think about it. Security team sets specific ports and policies that they allow. The developer or operations team can just automatically check it against what they already have in their manifest, generate a network policy. We can check that in. We can validate it against it. If we get the green light, then it goes to test. If it doesn't, maybe it breaks the pipeline. There's a lot of flexibility in how you want to bring this into your workflow. So again, users can make changes to the proposed connectivity, and then these changes can be automatically updated. Let's say the security team has decided a certain port is not allowed, and you have a massive organization with a lot of clusters, well then we need to make a change and make sure that all of our network policies across are validated. So we can do this automatically in a CICD pipeline. So for that workflow, we want to be able to help simplify and scale it. I know it's the best buzzword ever, but really it's about allowing the operations and DevOps teams to have the flexibility of how they implement it, because we want the security teams to feel safe in the applications that are running. Now to sum it up, I'll keep it quick because it's early Monday morning and the coffee's kicking in. So if you'd like to see the project in action, I'll be outside at the Red Hat booth. You can also download the Stack Rocks open source platform. It's free to use. It has the developer preview flag in action right now if you want to check it out. Again, I guess I said free to use. And you can also take a look at the MPGuard project. It's a project on its own as well. And then I know we have a couple other people I want to give a shout out to. And Luke Hines is in here. He's doing six-store con tomorrow at 9.15. I'll be there checking him out too. And again, I'll be at the Red Hat booth outside if you want to learn more and see it in action. Thank you so much, everyone.