 Hello, welcome everyone to this talk about embracing policy as code in Kubernetes with Gatekeeper. My name is Sara Poulida, I'm a technical evangelist at Datadoc, and that's my Twitter handler if you ever want to reach out. So let's get started. So this talk obviously is not about Datadoc itself, but just so you know, Datadoc is a monitoring and analytics platform that helps companies improve observability of their infrastructure and applications, but this talk is about policy and policy in software. So what do we mean by policy? So basically, policy are the rules that governs the behavior of a software service. So basically what you can and cannot do in a particular software service. So when we talk about Kubernetes and what you can and cannot do, that sounds very familiar to RBAC. RBAC is role-based access control, and basically you can create rules about a particular subject for a particular resource in Kubernetes, can or cannot do a particular verb. So you can create rules that says ARRA, for example, for resources of type POD, can create, get and watch those resources. So if we already have RBAC in Kubernetes, why do we need something else? And the reason why we need something else is because of, it's just a very small subset of all the policy rules that you may want to create for your software. To put a couple of examples of things that you may want to control on your software and Kubernetes on your cluster, things like, can I run a particular image coming from a third-party registry, or has my part all the labels that are required by my organizations? Those two things cannot be described with RBAC rules. So we need something else, and this is where OPPA, or Open Policy Agent, comes into play. OPPA is a CNCF project, so the FOA is completely open source, and basically it tries to decouple policy decision-making from policy enforcement. So OPPA, basically the only thing that it does is gets a policy query in JSON format, and based on some policy that you store in a particular domain, specific language called Rigo, and some data, it returns a policy decision also in JSON format. So completely domain agnostic. So now that you have that decision in JSON, how do you enforce that for your software? So you do that through any of the integrations that you have. So if you go to the OPPA website, you can see that there are a lot of integrations already there, and many more come in all the time, because it's very domain agnostic to JSON. So this is where Gatekeeper enters. So Gatekeeper is an enforcement of OPPA policy, specific for our communities. So it embeds OPPA as a library, and then the way it enforces policy in communities is through admission controllers, in this case admission webhooks. So when you have an APA requesting communities, once it goes through authentication and authorization, it goes through admission controllers. And there are two special ones called validating admission webhook and mitigating admission webhook. And this is where OPPA hooks into those admission web controllers. Right now, it only has a validating admission webhook to basically validate that it's allowed or denied a particular request, but they're working also on amortizing admission webhook to allow you to also mutate the request if that's what you want. One of the great things about Gatekeeper is that the Kubernetes native. So all the policy is going to be stored at CRDs. It extends the Kubernetes API with CRDs, and then it has a controller that does the reconciliation looping Kubernetes that we all love. So the great thing about that is that you can store your policy as you store any other configuration for your Kubernetes cluster, and you can apply best practices like GitOps, for example, also for your policy. But it also makes reuse policy very simple because your policy basically is just a template of any policy that you want to create. And then you instantiate that policy into as many constraints as you want. How does that work? So the constraint template is an object where you describe a set of parameters for your policy and a set of rigor code. In this case, for example, for required levels, we have just a property for the number of labels that we want to require. And then you instantiate that into as many policy rules, as you want. For example, with just that template, we can have these two very different rules. We can say that all namespaces require the Gatekeeper label, but all the pods required do not delete label. That means that Gatekeeper, again, makes reuse of policy very simple. And the good thing is that a great way to start with Gatekeeper policy as code is that many of these rules are very similar to as many users in Kubernetes as we can think of. Probably you want to create rules about images only coming from approved registers, for example, mandatory labels in your deployments, images needing to contain IDegis, for example, limits, CPU and memory limits to be set for all containers. All these things, it's fairly common. And this is where the Gatekeeper community is excelling. It has this Gatekeeper library with ready to use constraint and plates that you can reuse to create your own rules for your cluster. So this is a screenshot of the Ripper right now with all the different ones that you have. The great thing is that that library doesn't only have the constraint template. For example, it has this constraint template for ingresses being HTTPS only. But apart from the template, it also has examples. It has examples about constraints that you so instantiations of that constraint template and also objects, in this case, an ingress object that will fail that example. So that way, very simple, and we will see how in the demo, using that library, we can start creating rules that are specific to our cluster in a very simple way. And again, without needing to know a lot of rego to start with. So this is where you find the Gatekeeper library. It's part of the OPA project, so again, completely CNCF open source. And another point that I love about Gatekeeper is that it comes with observability baked in. So you have some out-of-the-box metrics like the number of constraints in place and constraints that you have, number of requests to a hook and latency, number of violations, et cetera. With those metrics, we also have an out-of-the-box integration with Datadoc. So if you're a Datadoc user and you're a Gatekeeper user, there's nothing else you need to do. It will be integrated for you directly, and you will have this out-of-the-box dashboard to start with as well, as we will see in the demo. So let's watch the demo. The demo is pre-recorded, and the reason why it's pre-recorded is because we don't have a lot of time, so it can go very quickly. We have a one single node cluster running Datadoc already and running keep system pods. And we have here the pods that are currently running, the deployments, replica sets, et cetera. Everything is running, but Gatekeeper is not running yet. So let's apply the default YAML file that we have in the instructions. Once we have applied, we have new CRDs, as we said, and we also have the controller pods that you can have many replicas you need and the audit pod that we are going to explain in a second what it's for. So as soon as we have Gatekeeper running in a cluster, the Datadoc agent is going to realize that it's running, and it's going to enable the Gatekeeper integration automatically. So you can see that it's already running and sending data to Datadoc. So let's use the Gatekeeper library to reuse some of these already made templates. In this case, they require labels. So it has a description, it has a set of parameters, and it has some rigor code. But as I said, these things have examples as well. So it's going to be super easy to reuse. Let's apply first the template itself. And once we have applied the template itself, a part of having the template object, we already have, we also have a new CRD, the Kubernetes required labels one, that now we can reuse as many times as we want to create as many roles about required labels as we want. This is the example that comes with it, but we are going to reuse it. So instead of name spaces and owner label, we are going to copy that one, and we are going to see how it says to reuse this thing. So let's copy just the code as it comes from the repo, and let's start editing. So instead of the owner label, we are going to require the KubeCon label, because we are at KubeCon, and instead of name spaces, we are going to require parts, and we are going to remove the rejects of it. So we are only going to require the key with any value that we want. So let's apply that constraint, and now it should be working, but we already had some parts already running in a cluster without that label. What happens in that case? So instead of removing those parts, this is where the audit part comes into play. It's going to check the running objects that are failing a particular, that are violating a particular rule, and it's going to put it here with all the information. That way you can introduce new policy into your cluster without having to remove all the things that are not. You can check the audit logs and then modify your objects to match that. So if you go now to data doc, you can see that suddenly we have those violations also in our dashboard. You can see that those 14 violations are coming from the 14 parts that were already running in our system, but didn't have that label to start with. We can also see the number of requests that we are doing to the webhooks, the latency. We can see the logs coming from all the GitKeeper pods that will give us some hints about possible denials. But what about new objects? So if we have this nginx pod that we want to create, doesn't have the label, it's going to fail. So for new objects, that enforcement is going to happen, and it's going to give you an explanation why you cannot create that pod. So if now we change and put a KubeCon label that is required, KubeCon Europe, because we are in KubeCon Europe, and then we try to apply it again, then it's going to work. So this was a very quick introduction about GateKeeper and how you can use it today to enforce policy. Again, it's important at some point to learn Rigo if you're going to use GateKeeper and OPPA, but to start with using the GateKeeper library, it's going to give you a lot of value just without having to learn Rigo just now. So I hope you enjoyed, you learned something. If you want to learn more about GateKeeper, there are a lot of documentation out there. Also, if you want to come and join us in Datadog, reach out to our careers page. We're using GateKeeper internally as well. So if you're interested about that, reach out and thank you very much.