 So, we will be talking about a successful recipe to secure your fleet of clusters using GitOps policies and service mesh, all this in 10 minutes. So we'll cover the ingredients of our recipe, which is GitOps, OpenGateKeeper, Istio, we'll bring it all together using an architecture diagram, and we will do a demo. And yes, our slides are available at this link. So if you download the PDF, you will have access to all of our slides. The first ingredient of our recipe is GitOps. If you have a small, you know, a few clusters, you can always do some context switching. You can connect to your clusters. You can do a Qubectl apply to apply the configs, policies, deploy your application. And that works well. And as you start having a large number of clusters, tens or hundreds or thousands of clusters, that approach typically falls apart very quickly. And oftentimes, if you have a large enterprise, there are people within your enterprise who have to work with one another, such as a security admin, a platform admin, application developers and operators, because security is everybody's responsibility. So you can do this by having a single source of truth for your configs, for your policies, and for your app manifest. And typically the way you can build this system at scale is you can have, you can build CI CD pipelines from your Git and use a product like config sync or Argo CD to sync those configs onto your clusters. So moving on, and we'll show you how all of these different personas work with one another using Git in our architecture diagram. The second ingredient of our recipe is OpaGateKeeper. OpaGateKeeper enables you to write policy as code and provides you multiple enforcement points for your policies. So starting with CI CD, you know, you can shift way left using OpaGateKeeper. And then the second step is during the admission time, you can check if the incoming resources allowed on your cluster or not. And after the effect also, you can configure a continuous audit of your resources on your cluster. So you are always making sure that the target state that you have specified for your resources is actually the actual state. And it does that by letting you define a constraint template. So a constraint template has the rego, which is the actual policy logic. And it does have a schema for the constraints. And multiple constraints can actually use the same template, but you may have different parameters that you're passing through each one of these constraints. And which means you are maybe enforcing or auditing a different rule. So you can use OpaGateKeeper to implement security, governance, or compliance for your Kubernetes clusters. Moving on, the third ingredient of our recipe is Istio. We won't go into details of everything that Istio does. But for this talk, Istio enables the service-to-service communication securely at scale. And it also helps with traffic shaping consistent observability for your services and applications. And it is a layer seven Roxy has a control plan and data plan. So moving on, you know, now we talked about all the three ingredients for our recipe. And I will hand it over to Matthew to bring everything together. Perfect. Thank you, Poonam. So actually, let's put the three ingredients together, right? And as a platform admin, I want to provision my clusters, the fleet of my clusters. In there, I want to install a GitOps engine, in our case, config sync. If you're using Argo CD, Flex CD, it's working Istio as a service mesh. And then I want to make sure that the security admin, she is able to deploy and actually design and code their own gatekeeper policies constraint and constraint template on their own and in their own Git repository. And with that, we could sync and deploy those policies across the fleet of clusters. The other persona we just saw earlier is about the apps operator. I want to deploy apps. I want to ship value for the end user, right? So how I could be onboarded and deploy actually the manifest of my apps. But finally, what we want to do is having this enforcement of policies of gatekeeper policies in our case at different level, right? One example could be locally on the pre-commit hook with the app operator designing and coding their own policies and actually manifest, sorry. But evaluating against the policies designed by the security admin, right? The second step could be on a pull request review, right? Or merge request if you're using GitLab. Another step, the third step here, like Prunam Illustrated, having actually OPA gatekeeper as an admission controller in your cluster, right? Different level of enforcement. So actually, let's see a demo about that here. What we want to show you is actually a repo that you could reuse here. And we have different folders where we are deploying, for example, the Ingress Gateway, right? We are deploying some config for Istio to have some security best practice in place. We have application, but we have also the policies here. It's in one repo. It could be in multiple repo for the purpose of this demo. It's one mono repo for all of that, right? The policies, I don't know if you're familiar with gatekeeper, but typically I have some constraints. And here the constraints are all about security best practice and features with Istio. We took three examples, having MTLS strict across the mesh, right? Having also the cycle injection for any namespace in this mesh, and not having anyone bypassing, for example, on a pod, having this bypassing annotation to opt out for being part of the mesh. Here we are also, like I mentioned, forcing the strict MTLS for the mesh. And avoiding, if you are familiar with Istio, some concept where people and apps operator could bypass actually the mesh wide configuration. That's part of maybe seven or eight constraints here. We are forcing also authorization policies to have fine granular communication and policies in place between the different microservices within MyMesh. What I want to show you here is actually as an apps operator, what I want to do is deploying an application, right? So if you see it quickly, I have a service account, a service deployment. But what I'm doing also is trying to bypass the injection of my pod, my deployment, right? I'm also not injecting the label and the cycle proxy injection. I'm also disabling the MTLS strict. So what I want to show you here is I'm not doing that in a cluster, but look at the pull request checks here. Actually, the CI is complaining here, right? And that's interesting information that I could have here. And if I look, for example, at the summary of this information here, I could see in more details that I'm running Gator test. And I'm not able to see you in details here for the technical issue we had earlier, but here I'm running Gator test. Gator is a CLI provided by the Gatekeeper project, CNCF project around OPA, actually. And these Gator tests will help me to test my manifest or any manifest coming in in this pull request against the security policies and Gatekeeper policies of my company. So here I could see I could fail fast and shifting left the evaluation of such constraint, right? So I'm making sure that the apps operator are not at all bypassing such security best practice for Istio. And I'm not waiting to have that actually in my cluster, right? So here I have another pull request, the same app, but without trying to bypass the best practices. And here all is green. The check is very happy about the evaluation of my policies. Gator got a successful here validation. And the rest of the demo that you could reproduce with the GitHub repo is about, hey, I'm a platform admin, and I don't want yet to merge this pull request to deploy this application from the app operator. I want to test that on a staging cluster, pre-prod cluster, right? So for example here, what we are doing is actually targeting this configuration for GitOps, configsing, and targeting not anymore the main branch, but we are targeting this feature branch. I want to test it and deploy it, synchronize this application, manifest with the staging cluster, right? So here what I could do, but we don't have time for that. Merge the pull request and seeing the deployment on the cluster, testing and seeing that it's injected in my mesh with security best practice. And that's the end to end flow for making sure that any deployment is actually secure and following the best practices. And that's it for the demo. Great, thank you, Matthew. And to wrap this up, we tried to do everything in ten minutes, but you do have access to the demo that Matthew and I put together. And you can play with it yourself. But to wrap it up, if you look from left to right, we showed you how you can shift left for your policies. If you use Google Cloud or GKE, you can also try policy controller, which is actually based on top of Gatekeeper. And you get value out of it really quickly. And then last but not the least, on the right-hand side, you see some additional checks, like if mutual TLS is enabled on your mesh or not, along with some other policies. And you get the status of all of these out of the box. Again, there is a link to the demo. There is another talk in the same room in one hour where Matthew is going to go a little bit more deeper into building and deploying the OCI artifacts with home charts, the GitOps way. And I will be available on the Google Boot P25 on Thursday. And if you have any questions about policy, come find me for Kubernetes governance, security, compliance. We can have a conversation on those topics. All right, thank you so much. Thank you everyone.