 Hi all, welcome to this talk slash demo about how we can enforce policy and ingress. The on-route index controller API gateway indicates with the open policy agent, which you can use to enforce with the policies. Of course, you can join the Slack channel. Feel free to ask questions through the contact page. If you need help or support, Slack is a good way to reach us. That's me and Chintan Thakkar, founder at SARAS. This talk is going to be about on-route. It's how on-route is a lightweight model of filters. So we'll go over how the integration with OPA works. What are the filters involved? What are the filters we are going to use for this demo? We are going to work a bit with JSON web tokens, so we'll use a filter for that. Anvoy has a Jot filter, so on-route programs that filter and the provider is going to be Auth0. Along with that, we are going to use the external authorization filter, which we'll talk to OPA. We'll program some policy on OPA and see it being enforced. This is the high-level architecture. On-route has a very modular architecture. It's a lot similar to how on-route does it. On-route is a fairly lightweight Shimano on-route proxy. You can enable, disable all these functions like OIDC or SSR, TLS, logging, WebAssembly, 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 window service. So here, especially, we are going to talk about how we send request state to OPA, OPA checks the policy and return response depending on what the policy does to the incoming traffic and will sort of inspect the whole cycle. On-route one step, it is for North-South security and traffic management. It sits at the ingress and the one-step configuration essentially you can declaratively, without writing any annual, execute one command and have the required policy enforced for your traffic. And of course, it's all CRD, so it's Kubernetes native. It's built on on-vibroxy, of course. And yeah, this is one of the key things. You can define policy once. You can use it for Kubernetes. You can also use it for non-Kubernetes workloads because on-route 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 it is declarative with no YAML because without writing YAML, you can basically program the standard function. So for instance, in today's demo, we are going to enable the Jot filter and that was just set up by executing a help command with the Jots which turned on. There are three versions of on-route. The open-source version, the community and the enterprise. The open-source source code is available on GitHub. The community version has premium filters like rate limits, WASM, which are typically paid plugins, Jot, you know, I mean typically other gateways. Jot, what is this? These are all free in on-route and the enterprise version has a few additional filters, OPAS and enterprise plugin features. You can check out all the features on the get on-route page. 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. It's attribute-based access control over RBAC. Typically an example of an RBAC would be restrict access to finance app or to CFO org or the finance org. So anytime a user comes in, they get mapped to the corresponding role like a finance rule and then the enforcement happened. Whereas in attribute-based, you can provide richer policies like restrict access to a finance app to the CFO org while the CFO, the person who's 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 during this time duration. So it sort of provides a very rich layer of attributes that you can use to define your policy and OPAS is the right tool to do that kind of stuff. So for this demo, we have a system setup. So we have already installed on with the OPAS integration and then we have installed an example workload in HTTP bin. We have installed the Jot filter and the idea behind this is that all these things are available on the getting started guide. The getting started covers how to set up the Jot filter. So we're 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 on root setup and the Jot filter is enabled. By the way, this OPAS plugin details are also on the docs page. There's also a very small video of how OPAS is enforced. So there's some information about the OPAS integration with on root on the page and also of course how the configuration looks like and some OPAS policy. But we're going to look at the OPAS 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 the stuff, the enforcement of Jot claims and the OPAS policy. So we are focused on that aspect. So let's quickly invoke a request. So we have HTTP been set up and what we are seeing here is that it got denied. So let's do that again. So here we can see that Envoy does not like the request because the Jot filter is enabled and we have not sent it a Jot. So let's quickly look at the filters installed here. So here we can see we have the Jot filter which is enabled. As far as the Lua filter got programmed and then we also have the external OZ filter. This is the OZ filter that essentially helps us talk to OPAS. So we have OPAS running along with on root and the external OZ filter is configured to send request to OPAS to verify policy. And let's also look at the filters. So we have the Jot filter set up. So note that these all filters got set up automatically once we specified those switches on the help command. It just sets these up. We are going to use OZ0 for our test. So OZ0 is the GWorks provider and we are going to see how we'll send a Jot token and it is talking to OZ0. We have an account on OZ0. So it's talking to OZ0 to verify the token. So let's quickly generate our token here. So here we have several different types of permissions that we have defined. Read finance, read marketing, write finance, write marketing. And for this specific example, let's go ahead and provide the read finance permission. Now we'll do a deep dive into the OPPA policy but just to get going with the demo, the read finance is something that OPPA is going to deny because what we have programmed OPPA for is only allow requests through which have the write finance permission. So read finance will be ignored but at least we won't get a message saying the Jot did not get verified. So there are two gates here. The first gate is the Jot gate and once we pass the Jot gate, Anwar is going to send it to the external OZ 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 write finance and it's going to deny the request. So let's just quickly send that header here. That's the header. So now we are getting a 403 forbidden. Of course that's coming from OPPA and maybe we can look at the OPPA logs. So let's quickly look at the logs here and we see the result as false. So that's why we are getting a 403 for our request. So that's the request on the post. So we're going to inspect the OPPA policy in more detail but this is just to get started. So earlier we sent a request without the Jot and it got kicked out by Anwar and now we're going to send a request with the Jot with a valid Jot. So Anwar is going to be okay with that but at the same time OPPA is not going to like it. So that's that and now let's continue with the presentation. So yeah, this is the same thing I mentioned earlier. So there are a couple of filters used here. First is the Jot filter and the second one is the OPPA filter and once the Jot is verified the Anwar Jot filter and if the Jot is valid it's sent to OPPA. OPPA verifies the claims. The OPPA verification of claim generates and allow or deny. We got to deny this time and then if the claim is valid it's sent to the service. So let's quickly look at how the OPPA policy looks like. We are only going to allow requests which have a claim of right finance. So now the request we sent let's quickly look at how the claims on that works. So here we can see the scope of it is read finance and this is the same thing that we had used here to generate the read claims and essentially OPPA doesn't like it. So here let's even look at the OPPA policy. So here is the OPPA policy and what it does is it extracts the it takes the authorization header and it extracts the token from it. So it moves past the better string and then once it has the token the token gets decoded. So you get the token. The token gets decoded and once you have the payload the payload has the claims and then you want to ensure that the claims have right finance in it and what you're going to query against is envoy or to Z allow. So the request is going to get allowed if you find this claim but like we noticed like we checked in the current request the claim is read finance which is what we will of course sending and now let's just quickly send a write finance kind of claim and ensure that it gets to go through. So let's use that. So now the request went through and that is because OPPA policy was able to evaluate and allow through. So let's quickly look at the OPPA log again and see what it shows. So here we see the result was allowed and it called the authorization header. This is the authorization header that it passed to extract the token and extract the claims out of it and verify it. So that's sort of a high level demo of the OPPA integration. Let's quickly look at the OPPA policy a little more. So what we are saying is the method should be post, the path should be post and you should have a claim that needs a write finance right. So even if we do a separate path it's not going to like it right. So let's try to get this is typically a valid path but OPPA should deny it. So this time it just denies it because the policy doesn't allow for that. So the policy only allows post on a post path. So that's pretty much what I had and that concludes this session. So feel free to try out on-road gateway if you need to use OPPA or Azure as a message and we can work with you to help you try it out. Thank you.