Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 15 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Session: Datadog - Policy-as-code for Kubernetes with Gatekeeper

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Sponsored Session: Datadog - Policy-as-code for Kubernetes with Gatekeeper

Speakers: Ara Pulido

As more enterprises migrate to cloud native environments like Kubernetes, the need for scalable ways to define and enforce fine-grained policies increases: how can I limit the number of replicas of a pod for certain users? how can I ensure that all images come from trusted registries?

Gatekeeper is an open source project to integrate Open Policy Agent (OPA) in Kubernetes environments. Gatekeeper allows to define policy as Kubernetes objects, making it easier to adopt policy-as-code practices in Kubernetes environments and sharing reusable policy templates.

In this demo we will explain how to set up Gatekeeper for Kubernetes environments. You’ll learn how to adopt policy-as-code techniques and how you can integrate Gatekeeper with your existing tools.

A

Hello welcome everyone to this talk about embracing policy as code in kubernetes with gatekeeper. My name is sarah pulido, I'm a technical evangelist at datadog and that's my twitter handler, if you ever want to to reach out so let's get it started.

A

So this talk obviously is not about datadog itself, but just so you know, datadock is a monitoring and analytics platform that helps companies improve observability of their infrastructure and applications. But this talks about policy and policy in software. So what do we mean by policy?

A

So basically policy are the rules that governs the behavior of a sovereign 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 our back. Hardback is role based access control and basically you can create rules about a particular subject for a particular resource in kubernetes uh can or can do a particular verb, so you can create rules that says uh ara, for example, for resources of type pod can create, get and watch those resources.

A

So if we already have our bag in communities, why do we need something else and the reason why we need something else is because off 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 server 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.

A

Those two things cannot be described with our back rules, so we need something else, and this is where oppa or open policy agent comes into play. Oppa is a cncf project. So therefore, 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 to make agnostic.

A

So now that you have that decision json, how do you enforce that for your subwoofer? So you do that through any of the integrations that you have so you. If you go to the oppa uh website, you can see that there are a lot of integrations already there and many more coming all the time, because uh it's very um domain agnostic, it's just json. So this is where gatekeeper enters.

A

So gatekeeper is an enforcement of oppa policy uh specific for kubernetes, so it embeds operas a library and then the way it enforced policy in companies is through admission controllers, uh in this case admission web hooks. So when you have an apa request in kubernetes once it goes through authentication one authority station, it goes through and mission controllers and there are two special one called validating admission web hook and mutating mission web hook, and this is where oppa hooks into those admission web controllers.

A

Right now it only has a validate and mission web hook to basically validate that it's allowed or denied a particular request, but they're working also in a mutating admission webhook to allow you to also mutate the request. If that's, what you want, one of the great things about gitkeeper is that kubernetes native. So all the policy is going to be a store at crd, so it extends the kubernetes api with crds, and then it has a controller that does the reconciliation, looping kubernetes, that we all love.

A

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 uh best practices like keytops, for example, also for your policy, but it also makes 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?

A

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 labels. We have just a property for the number of labels that we want to require, and then you instantiate that into as many policy as 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 pots required that do not delete label.

A

That means that gatekeeper again makes reuse of policy very simple, and the good thing is that and 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 eye digest, for example, limits cpu memory limits to to be set for all containers.

A

All these things it's fairly common, and this is where the gatekeeper community, it's exciting.

A

It has this gatekeeper library, with ready to use constraint, templates that you can reuse to create your own rules for your cluster. So this is a screenshot of the um of the of the reaper right now with all the different ones that you have. uh But the great thing is that that library, that doesn't only have the constraint template, for example, it has its constraint template for ingresses being https only, but apart from the template, it also has examples.

A

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 rigo to start with.

A

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 comes with observability baked in so you have some out of the box metrics, like the number of concern, templates and constraints that you have number of requests to a hook and latency number of violations etc.

A

With those metrics, we also have an out of the box integration with data doc. So if you're, a data user and you're a gatekeeper user, there's nothing else, you need to do.

A

It will be integrated for you directly and you will have this out of the box um dashboard to start with, as well as we'll see in the demo. So let's watch uh 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 we can go very quickly. We have a one single node cluster running data dock already and running, keep seats and pods, and we have here the parts that are currently running the deployments: replica sets, etc.

A

Everything is running, but gatekeeper is not running yet. So, let's apply the default emf file that we have in their instructions, one we once we have applied. We have new crds, as we said, and we also have the controller pots that you can have as many replicas you need, and the audit part 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 data talk agent is going to realize that it's running and it's going to enable the gatekeeper integration automatically.

A

So you can see that all it's already running and sending data to datadog. So, let's uh use the gatekeeper library to reuse some of these already made templates, in this case the required lab labels. So it has a description.

A

It has a set of parameters and it has some rigor code but, as I said, these things have uh 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 power of having the template object. We already have. We also have a new crd. The kubernetes required labels. One then now we can reuse as many times as we want to create as many rules about required labels as we want.

A

This is the example that comes with um with it, but we are going to reuse it so, instead of namespaces and owner label, we are going to copy that one and we are going to see how it says to to release this thing. So, let's copy just the code as it comes from the repo and, let's start editing.

A

So, instead of um the owner label, we are going to require the kubecon label because we are kubecon and instead of namespaces, we are going to require parts and we are going to remove uh the rejects um of it. So we are only going to require the key with any value that we want.

A

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 with 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 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.

A

You can check the audit blocks and then modify your objects to match that. So, if you go now to datadog, 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 pots 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 wet hooks the latency.

A

We can see the logs coming from the all the parts, uh gatekeeper parts that will give us some hints about possible 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.

A

That, unfortunately, is going to happen, and it's going to give you an explanation why you cannot create that um that part. So if now, we change and put a kubecon label that is required, kipcom europe, because we are in cubico in europe and then we try to apply it again. Then it's going to work.

A

um So this was um 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, is going to give you a lot of value just without having to learn rigo just now.

A

So I hope you enjoyed you learned something if you want to. um If you want to learn more about gatekeeper, there are a lot of documentation out there.

A

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.