Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2021, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction to Open Policy Agent - Ash Narkar, Styra & Rita Zhang, Microsoft

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.

Introduction to Open Policy Agent - Ash Narkar, Styra & Rita Zhang, Microsoft

Come to this session to learn about the Open Policy Agent (OPA) project. OPA is a general-purpose policy engine that solves a number of policy-related use cases for Kubernetes, microservices, CI/CD, cloud, and more. During this session the OPA maintainers will introduce the project for newcomers and then provide updates on the latest and greatest features landing in OPA and OPA Gatekeeper. If you are interested in policy and security as it relates to cloud native technology, this session is for you.

A

Thank you for joining us for this intro talk on the open policy agent. My name is ash narker. I am a software engineer at styra and I'm one of the maintainers of the open policy agent. I care about developing software that can be easily deployed scaled managed and is secure by default.

B

Hi, I'm rita, I'm a software engineer at microsoft and I'm also a maintainer of the oppa gatekeeper project. I'm a firm believer that gray. Software requires user empathy.

A

In today's talk, we learn a bit about the open policy agent, its features we look at its roadmap and then we'll get some updates from sub projects like conf test and gatekeeper.

A

So, let's get started, the oppa project was started in 2016 at styra, and the goal of the project has been to unify policy enforcement across the stack one of the earliest adopters of oppa was netflix and they've been using oppa for authorizing their grpc and http apis and companies like chef, cloudflare, pinterest, intuit capital, one and many many more are using oppa in production for a variety of use. Cases like admission control, our back abac risk management, data, filtering and so on.

A

Oppa is a graduated project at the cncf, with more than 150 contributors on github. It has a healthy slack community of more than 4500 members. It's been starred more than 5000 times on github and it's integrated with more than 50 of the most famous open source projects out there, some of which we'll see later on.

A

So, let's look at this policy enforcement problem. If you look at the cloud native landscape, you know that is constantly evolving. There are new projects that get added every day like a new database or a new gateway, a new service mesh and so on.

A

So if you're building a system comprising of all these projects, your system is going to have a lot of moving parts and if you think about security, specifically authorization for such a diverse system, you can think of each of these projects having a different way of controlling access which may be tightly coupled to the underlying system.

A

Each of these projects could be written in a different programming language, and so, when you're building your system with all these moving parts with such a diverse set of projects, you end up having no visibility into the security posture of your system, even from a flexibility point of view.

A

Imagine if you had to swap out the service mesh tomorrow so now you have to again spend time and money to confirm these policies to your new service mesh and, you might say, we'll just use docs and wikis to enforce policies until you have tens, hundreds or even thousands of these services and the wiki approach is no longer sustainable.

A

So what we need is a unified way to control access across all these diverse systems, and this was one of the motivations behind creating the open policy agent.

A

We'll check out this slide again later, but for now, let's look at what is the open policy agent? So oppa is an open source. General purpose policy engine when you use oppa, you are decoupling. The policy enforcement from the policy decision making, so your services can now offload policy decisions to oppa by executing a query.

A

So let's understand this concept a little more using this figure. Imagine you have a service, and now this can be any service at all. It can be your own custom service, kafka, kubernetes, envoy, sto, any service at all.

A

Whenever your service gets, a request, is going to ask oppa for a policy decision by executing a query.

A

Oppa is going to evaluate this query based on the policies and the data it has access to and send a decision back to your service where it gets enforced.

A

So you can see that we have decoupled the policy decision making from the policy enforcement.

A

The policy query itself can be any json value. So, for example, if you're doing kubernetes admission control, the policy query could include your pod, manifest, for example, or if you're doing http ap authorization. The policy query can contain your request path, your method, the user and so on.

A

The policy decision also can be any json value and then it's up to your service how to interpret that decision.

A

So this is our overview of how oppa works with your services.

A

Now, let's look at some of oprah's features at the core of oppa is a high-level declarative language called as rego and with rego. You can write policies which are more than allowed deny through false. Yes, no, your policies can be sets objects, collection of values, strings and so on.

A

So oppa can help you answer. The question: can bob access a particular field and also oppa, can help you answer the question? Which fields can bob access, so the policy decisions can be much more expressive using rego oppa is written in go and uh you can deploy it as a sidecar, a host level daemon. You can embed it inside your go code, and now you can also compile your lego policies into wasm and use those executables to answer your queries.

A

It's designed to be as lightweight as possible. So all the policies and all the data it needs for evaluation is stored in memory.

A

You can think of oppa as a host local cache for your policy decisions.

A

Oppa does not have any runtime dependencies, meaning it does not have to go to an external service to make a policy decision. It does not have to contact an external database to make a policy decision. You can extend oppa to do that, but that's completely optional.

A

Oppa does provide you with some management apis which allow you to pull policy and data from a remote service.

A

Oppa also uploads the logs the decisions that it makes to a remote service which allows you to debug it for offline auditing and ogba can also update its own health, its own status to an external service.

A

Finally, with the along with the code policy, engine oppa provides you with a rich set of tooling, which allows you to build test and debug your policies.

A

There is a unit test framework which you can use to test your policies before you actually deploy them. There are integrations with ides, like rim vs score intellij, to help you better author, a policies using red- oh so these were some of oppa's features, high level, declarative language, multiple deployment models, management, apis and a rich tooling set.

A

So we've seen this figure before and the reason oppa is a general purpose policy engine is because it's not tied to any particular data format.

A

As long as you give oppa some structured data and you write policies that make sense for that data. Oppa gives a decision back to you and that's why it's a general purpose policy engine- and this is just a snapshot of all the projects. Oppa is integrated with there are much much more and the cool thing is. You can take any of these integrations out of the box and without having to light even a single line of code. You can use oppa, along with these systems, to enforce custom security policies.

A

So, like I mentioned before, the previous slide just showed a snapshot of all the integrations. If you check out the ecosystem page on the oppa website, you can find much more of oppa's integrations and if you would like to contribute to oppa, one of the best ways is to integrate oppa with your favorite project and then have it featured on the oppa website.

A

Next, let's look at oppa's roadmap, so the roadmap, which we release every year, is a snapshot of the work the community will tackle this year, and so one of the things we always try to do is improve our documentation to make it much easier to get started with oppa and to learn opel.

A

So one one of the things we are doing now is we are going to update all our tutorials to use our management apis like the bundles, the decision, log and the status to help users to get started with these in a very easy and intuitive manner.

A

Like I mentioned before, all the policies and all the opa oppa needs for evaluation are stored in memory, so your memory usage is going to scale with the increase in the policies and the data you load into oppa.

A

To give you an example, when you take raw json and you load it inside of oppa, it takes 20 times more memory as compared to the same data loaded on disk in a compact, serialized manner.

A

So now we are looking at ways in which we can store policies and data on disk and oppa can efficiently load them from disk during evaluation.

A

So there's some work and investigation going around a persistent storage for policy and data and, lastly, I'd like to point out uh the work we're also doing on uh bundles, wherein we are working on a new kind of bundle called the delta bundle.

A

So for those of you all not familiar with bundles bundles are basically gzip tarballs that contain policy and data, and so this bundle it represents the entirety of opa's policy and data cache.

A

Whenever you have new policies or new data, your service creates a new bundle, oppa downloads that bundle it first has to erase everything it has in its current cache, and then it can load this new bundle and start using the policies and data from that bundle.

A

But imagine if you had lots of data inside your bundle and you wanted to change just a small, tiny part of that data. You would have to create a new bundle. Oppa has to download that new bundle erase everything it currently has load. This new bundle. All of this work just done for that small change in data, so this is not a really good way to propagate these data changes, because you're wasting network resources, as well as open resources and so to help resolve this issue around propagating changes to oppa in a really efficient manner.

A

We believe delta bundles would be a good solution for that. So that's gonna come up later this year as well, and we've also been doing a lot of work behind uh improving the performance around wasm and that's gonna continue as well later throughout the year.

A

So this is a snapshot of some of the projects being taken on by the oppa community. This roadmap is publicly available and you can check it out in the github repository.

A

Okay, so now, let's get some updates from some sub projects, starting with conf test.

A

So, as you all may know, conf test is a utility to help you write structured to help you write tests against structured configuration data confess became part of the oppa family last year and we thought we'd share. Some updates from the project so contest now supports the github output format, and what this does is allows you to use confidence for checking incoming pull requests.

A

So now you can take this command and you can include it inside your github workflow inside your github actions and then github will annotate the file, which has the policy violation.

A

So this is a really cool feature that the confidence team has come out with.

A

Secondly, there's also the a new report flag that has been added to the contest verify command to help you debug failing tests in a much better way.

A

Third is the support for the new property file type, so contest supports a bunch of file types, json, xml, uh yaml, docker files ignore files, and now it's added support for the properties file type as well, and so what's next from the conference team. So they are working on a new and improved way to allow more fine-grained control over which policies to exclude.

A

So, if you all want to chime in on that check out the conscious repo check out the issues in the conference repo and add your comments and feedback in there, and so this was the updates from the conf test team and now for all things, gatekeeper, I'm going to hand it over to rita.

B

So, first, what is gatekeeper gatekeeper is an extensible emission controller for defining and enforcing policies over kubernetes. It leverages oppa under the hood for making policy decisions while providing a kubernetes native layer on which operators can define their policies once and reuse them across multiple contexts.

B

So how do we get here back in 2017 styra released cube management, a sidecar for loading, oppa policies from config maps in 2018, microsoft, released kubernetes policy controller and donated to oppa later that year, microsoft, google, styra and others began. Collaborating to reimagine policy management, the fruit of which became the gatekeeper project.

B

This diagram visualizes how an api request flows through the system kubernetes provides hugs for mutating and validating a request prior to emitting it into the cluster gatekeeper, integrates opa and rego into the flow to help make these policies decisions and for this kubecon we're introducing the external data feature which allows gatekeeper to connect to external data sources to help with policy decisions.

B

Gatekeeper core features, write policies as declarative configurations. It can be parameterized to encourage reuse, validating emission control control. What end users can do on the cluster. It also supports audit, which periodically evaluates resources against constraints to track compliance across time.

B

It also allows for ongoing monitoring of cluster state to aid in detection and remediation of pre-existing mis configurations and with dry run. You can gradually roll out new policies without breaking existing workloads.

B

Finally, with contacts awareness, you can define referential policies that enforce uniqueness of a field across different resources.

B

The gatekeeper api is built on top of the constraint framework. The constraint framework defines kubernetes based abstractions over policy in the forms of constraint, templates and constraints. A constraint template is a custom resource describing a parameterized rego policy to be enforced by oppa. A constraint is an instantiation of a policy which binds it to a particular context, using matchers, as well as providing arguments to customize behavior.

B

Now for project updates, let's talk about some of the new things. That's been happening to gatekeeper since the last kubecon.

B

We now have pre-alpha support for external data, leveraging external large data sets in our policy decisions.

B

Pre-Alpha support for gator test cli, which makes testing the yamls much easier for things like constraint, templates constraints and objects to be validated.

B

Enable support for kubernetes 1.22 moving the crds to extension, extensions, v1 and emission registration v1 constraint. Template crd now moves to v1 reduced system, mutate runtime by 87, fixed race conditions in watch manager and constraint, controllers prefix, based matching for namespaces and excluded namespaces.

B

This helps support various match sections across constraints, configs and mutation, integer, key values, support for mutation path, parser mutator, which helps us express path like to like this one to select items in a list, helm crd hooks to upgrade crds.

B

So we can update crds with helm, upgrade updated metrics reporting for mutation to track requests to the mutation web hook. The ingestion of mutator objects, number of active mutators in the system and the number of iterations across the system to mutate objects.

B

Last but not least, unified gatekeeper and control, a runtime metrics into a single endpoint. So now we can have publish the controller runtime and golang metrics by default.

B

Like last coupon, we introduced the new mutation feature in this kubecon. We're introducing a new pre-alpha feature that we've been working on for the past few months. Called the external data. External data allows us to validate and modify requests using external data sources before applying it to the cluster.

B

It is a generic provider-based protocol to extend access to external data providers to leverage large data sets in our policy decisions. This opens up new opportunities to strengthen security policies and establish security. Defaults.

B

Here are just some few use cases for validation. We can verify image signature before deployment against pre-configured public keys, based on the results. It can either accept or deny these requests.

B

We can also check for vulnerabilities of images against image, scanning tools and block. If vulnerabilities at a certain level are found for mutation, we can mutate image tag to digest, to pin an image to a specific digest.

B

We can also mutate labels to add owner's information with the aad user information of the operating performing the creation of those kubernetes resources.

B

Now, let's see a demo of this.

B

Here, as you can see, is a cluster that I have, and I have already deployed gatekeeper to this cluster and, as you can see, I have the control manager, pods and the audit running and here below are the new feature.

B

A new external providers, which works with the external data feature that we're adding and here, as you can see, we have four different providers for this demo. The first one is aad provider which mutates the labels to add owner information with the aad user information of the operator, who is running the command to create a particular kubernetes resource.

B

Next we have the cosine provider, which we are using to verify image signature before deployment against pre-configured public keys, based on the results it can accept or deny these requests, and here the external data provider is leveraging the cosign project from the six store project to verify the signature.

B

Next, we have the tag to digest provider which we're using to mutate image tag to digest, to pin an image to a specific digest.

B

Last but not least, we have the trivia provider which we're using to identify vulnerabilities of images before we're deploying them.

B

And here our external provider is the trivia server running in the cluster and the results will then be returned and we will be blocking if, if there are vulnerabilities found.

B

So here we have the tag to digest provider.

B

Here we have the mutate image: assign resource assign kind, is a custom resource for the mutation feature and, as you can see here, the mutation mutate image, assign resource is applied to deployments and it looks for all containers image and upon a an admission request. The request will be also sent to the tag to digest provider which is used to get the digest for the particular image.

B

So next, let's apply this as from a test, and here we, as you can see, we have a test deployment and we have two images. One has the digest. One only has a tag once we apply this.

B

Let's see the appointment is created and let's see if the digest was added and as you can see, yes, the digitalis static image now has the sha.

B

So for our next example, let's take a look at the cosine paul provider, and here we have a constrained, template kate, signed images and, as you can see, within the rego, it is calling the external data cosine provider and it returns the the image whether the image has a valid signature or not, and for the constraint where we have enforcement action denying and applying to deployments.

B

And here we have a unsigned example and it's applying to once. We apply it. Let's see if cosine thinks it's signed or not, and as you can see here, the request was blocked, because cosine identified that it does not contain a valid signature.

B

And here we have a sign example using a different image and then once we apply it, as you can see here, cosine provider did not block it because it has a valid signature.

B

Next, we have the trivia provider and, as you can see here in this constraint, template it is calling the trivia provider external data and here for the constraint, we're looking at all deployments with the worn enforcement action, and what is happening is when we apply the example here with the alpine image. It is going to call the trivia provider and the trivia provider will respond with the number of vulnerabilities scanned or identified, and here, as you can see it, what we received a warning because it contains over 30 vulnerabilities.

B

Here we have another example using a different container image and let's see if trivial will block that, and here, as you can see, it did not because it did not have any vulnerabilities.

B

Next, we have the aad provider, and here it is applied to config maps and it asked a owner's label using the aad provider.

B

Here we are deploying a config map and, as you can see here, we're deploying as a user who is an aad user and once it's applied once we apply the config map, as you can see the owner for the owner's label, we now get the user's first and last name from aad, and that concludes the four different providers to demonstrate. The external data feature in gatekeeper.