Cloud Native Computing Foundation Online Programs, 30 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Enforce Policy at Ingress using Open Policy Agent (OPA)

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hi all welcome to this talk, slash demo about uh how we can enforce policy and Ingress uh the art route index controller. Api Gateway indicates with the open policy agent which you can use to enforce, with Papa policies.

A

um Of course you can join. This live channel, uh feel free to ask questions through the contact page. If you need help or support uh slack, it slack is a good way to reach us. That's me: I'm chintan, Tucker, founder at SARS. This stock is going to be about on uh it's. How our road is a lightweight model of filters, so we'll go over how the integration with oppa Works? What are the filters involved? uh What are the filters we are going to use for this demo?

A

um We are going to work a bit with Json web tokens, uh charts so we'll use a filter for that. Envoy has a chart filter so on root programs that filter uh and the provider is going to be r0, and, along with that, we are going to use the external authorization filter, which we'll talk to Oppa, uh we'll program some policy on Opa and see it being enforced.

A

uh This is the high level architecture uh on Route has a very modular architecture. It's a lot similar to how Roi does it on Route is a fairly lightweight, shim or onward proxy, and you can enable disable all these functions like oidc or SSR TLS login web assembly. Of course, we also did a talk on webassembly and rate limiting Lua external authorization Opa. So all these are filters. A bunch of these are filters which you can enable disable at a high level to enforce policy for your traffic going to a service.

A

So here, especially we're going to talk about how we send request State to open checks, the policy and return the response, depending on what the policy does to the incoming traffic and we'll sort of inspect the whole cycle uh on Route One Step, uh it is for north-south security and traffic management. It sits at the Ingress and the one step. Config is essentially, you can declaratively without writing any yaml, uh execute one command and uh have the required policy enforced for your traffic and, of course, it's uh all crd. So it's kubernetes is native.

A

uh It's built on Envoy, proxy, of course, and uh yeah. This is one of the key things uh you can Define policy once you can use it for kubernetes. You can also use it for non-kubernetes workloads, because onroot has the ability to not only run as an Ingress controller, but you can also run it inside a Docker container as a standalone Gateway, and um it is declarative with no yamu, because without riding yaml you can basically program the standard function.

A

So, for instance, in today's demo we are going to enable the chart filter and that was just set up by executing a hell command. Helm command. With the chart switch turned on. uh There are three versions of onroot: the open source version: the community and the Enterprise. uh The open source source code is available on GitHub.

A

The community version has a premium filters like grade limits, vasm, which are typically paid plugins chart. You know, I mean typically other gateways charge for this. These are all free and on Route, and the Enterprise version has a few additional filters. Opa is an Enterprise plug-in features feature you can check out all the features on the get on Route page.

A

So, what's open policy agent, it's a general purpose policy engine. What that means is you can write any policy there with all the attributes and it'll do the enforcement uh its attribute based access control over our back typically, an example of an hour back would be restrict access to finance app or to ca for org or the finance arms. So anytime a user comes in. They get mapped to the corresponding role like a finance Rule, and then the enforcement happen. There is an attribute base.

A

You can provide richer policies like restrict access to a finance app to a to the CFO or while the CFO, the person who is accessing it, is at a specific location and only when they're using the specific device like that laptop and, of course, you can also say yeah during these time uh during this time, duration, so it sort of provides a very rich layer of attributes that you can use to define your policy and Oppa is. Is the right tool to do that kind of stuff?

A

So for this demo um we have a system set up, so we will. We have already installed onward with the OPI integration, um and then we have installed an example workload in HTTP bin. uh We have installed the chart filter and the idea behind this is that all these things are available under getting started guide.

A

um The getting started covers how to set up the chart filter. So we are not going to go over that stuff, but all the details can be found here, so you just set that flag and jot is enabled. So today, what we're going to assume is that we have onroot setup and the jot filter is enabled uh by the way um this oppa plugin.

A

Details are also on the docs page, there's also a very small video of how is opis and force so there's some information about the Oppa integration with onroot on the page and also, of course, how the configuration looks like and some Opa policy, but we're going to look at upper policy in more detail here. So the idea here is that the stuff in Gray we already have it set up and we are going to quickly go through uh this stuff. The enforcement of chart claims and the OPA policy.

A

So we're going to focus on that aspect, so, let's quickly um invoke a request, so we have HTTP bins set up and what we are seeing here is that it got denied.

A

So let's do that again so here we can see that Envoy does not like the request, because the chart filter is enabled and um we have not sent it a chart. So.

A

Let's quickly um look at the filters installed here so here we can see we have the joint filter, which is enabled, of course, the Lua filter guard programmed, and then we also have the external RC filter. This is the auth Z filter that essentially helps us talk to Oppa. So we have oppa running along with onroot, and the external RC filter is configured to send requests to opar to verify policy, and let's also look at the filters.

A

So we have the chart, filter setup, so note that these all filters got set up automatically once we specified those switches on the helm command. um It just sets these up. We're gonna use, auth 0 for our test. So odd, zero is, uh is the g box provider and we have. We are going to see how we'll send a chart token, and it is talking uh to auth zero. We have an account or not zero, so it's talking to r0 to verify the token.

A

um So, let's quickly uh generate a token here, so that.

A

So right so here uh so here we have uh several different types of permissions that we have defined. uh Read Finance, read marketing, right, Finance, right marketing, and uh for this specific example, let's go ahead and uh provide the read Finance permission now, we'll do a deep dive into the upper policy, but just to get going with the demo. The read Finance is something that Cooper is going to deny, because what we have programmed Opa for is only allow requests through which have the right, Finance permission.

A

So feed finance will be ignored, but at least we won't get a message saying the chart did not get verified, so there are two gates here. The first gate is the jot gate, and once we pass the jot gate um uh onward is going to send it to the external RC service, which is going to go to Oppa, which is going to verify the policy, and it's going to see that it doesn't have right Finance and it's going to deny the request. So, let's just quickly send that header here.

A

So that that's the header, so now we are getting a 403 Forbidden. Of course that's coming from upper, and here you can look at the OPA logs, so okay logs.

A

So, let's quickly look at the logs here and uh we see the result as false. So that's that's why we are getting a 403 saw it on red strength. So that's the request post, so we're going to inspect the uh oppa policy in more detail, but this is just to get started so earlier we sent a request without the chart and it got kicked out by Envoy and now we're gonna send a request with the jar with a valid chart.

A

So annoy is going to be okay with that, but at the same time oppa is not going to like it. So that's stuck, and uh now um let's continue with the presentation um so yeah. This is the same thing I mentioned earlier, so there are a couple of filters used here.

A

First is the jar filter and the second one is the opal filter and once the jot is verified um on to the Android filter and if the chart is valid, it's sent to Oppa oppa verifies the claims, the Copa verification of claim generates and allow or a deny. We got a deny this time and then, if the claim is valid, it's sent to the service.

A

So, let's quickly look at how the upper policy looks like um we are only going to allow um requests which have a claim of right Finance. So now the request we sent, let's quickly, look at how the claims on that units so.

A

So here we can see the scope of it is refinance, and this is the same thing that we had used here to generate the read claims right and uh essentially uh oppa doesn't like it. um So here, let's even look at the open policy, so.

A

So here is the uh Pupa policy and what it does is uh it extracts the um it takes the authorization header and it extracts the token from it. So it moves past the better uh string and then once it has the token uh the token gets decoded. uh So you get the token uh the token get the token gets decoded and once you have the play payload, the payload has the claims and then you want to ensure that the claims have right, Finance in it and what you're gonna query against is ryotz allow.

A

So the request is going to get allowed if you find this claim, but like we noticed like we checked in the current request,.

A

The claim is read Finance, which is what we were of course, sending and now, let's just quickly, send a right, Finance kind of claim and ensure that it gets.

A

Gets to go through so uh let's use that.

A

Right so now the request went through, and that is because uh profile policy was able to evaluate and allow crew. So, let's quickly look at the open log again and see what it shows.

A

So here we see that the result was allowed and it called the authorization header. This is the authorization header that it passed to extract the joint and extract the claims out of it and verified, so so that's sort of a high level uh demo of uh the Oppa integration. Let's quickly look at the OPA policy, a little more. So what we are saying is uh the method should be post, the path should be post and uh you should have a claim that needs a right Finance right.

A

So, even if we do a separate path, uh it's not going to like it right. So let's try the catcher. This is typically a valid path.

A

So this time it just denies it because the policy doesn't allow for that I think so the policy only allows post uh on a post path. So um that's uh that's pretty much what I had and that concludes this session, so feel free to try out on Route Gateway. If you need to use Copart or shoot us a message and we can work with you to uh help you try it out. Thank you.