 All right, so I guess I'll start now. Everybody hear me? Yeah? Great, thank you. So yeah, I recently, like an hour ago, gave a talk about Oslo Policy in general. Hopefully you enjoyed it if you were there. This one is a little bit about moving away from using Oslo Policy to evaluate your policies and using something else called Oslo Policy Agents. So why? While Oslo Policy in general works quite nicely, it's quite performant and it's been there forever, there's a lot of challenges that we did mention in our previous presentation. Just to recap, some of the challenges is that policy in general is not very consistent. There's a lot of issues regarding scoping, not working well, like admin being admin everywhere and not an admin for a project. So there's also the issue of not being able to refresh your policy live. So having service disruptions, having to restart Keystone in order to get your new policy working, stuff like this. So taking all of this into account, just also having the policy in the YAML format and having to go through each node and update the policy there, you'd probably need some custom Ansible or Puppet or stuff like that. So it is already quite painful. So having this into account, I was looking for a solution that would already be accepted in other communities. And I stumbled upon Open Policy Agent. It's a CNCF project, the same folks that do Kubernetes. So it's been getting traction. The community is quite healthy. So I thought, hey, why not take it into use into OpenStack? So this is where it all started from. So what's Open Policy Agent? The main thing about it is that it's a service daemon or a library that you upload your policies to. So your service will talk to it and will ask, can this entity do whatever it wants to do? OPA will answer that query. It has its own policy language, so it doesn't use the same language as a slow policy. But it has a lot of nice features, such as live reload. You can authenticate and authorize the queries towards those low policy using its own thing. So the same language that you use to write your own policy, you can have it for the policy for OPA itself. So there's a lot of cool stuff going on over there. It didn't go. It's quite performing. And when you do an update of your policy, there is no service disruption. It just reloads. So taking OPA into use, right? It's great. We have this thing. How do I use it? So Oslo Policy has the ability of writing custom checks similar to the external check like this one. But you can use that to override all of your policies with a very specific rule. So I wrote a custom one, and it looks more or less like this. Quite straightforward, just OPA, Cullen, and then the URI for OPA. It could be the same URI for all of your actions. You could have even point it to different OPA instances. But I don't really know what you would do that. But you can if you want to. And yeah, so the code is out there actually. Hopefully we can get that merged. But it has already right now really, really basic stuff, such as you can use TLS with it. I have not coded yet the authentication using a better token. But that should be just one header. It's very simple code. But yeah, I mean, OK. We have a check that we can use in Oslo Policy. Cool. But how, right? You still need to get OPA to authorize. You need to do stuff correctly. So for this, I wrote a tool. So this tool, what it does is that you give it your policy, your Oslo policy, the one that you've always used and that you're used to writing. And it will give you out this rego language that is used by OPA. So it's interchangeable. You can just keep writing Oslo Policy. You don't need to retrain your people or anything. And it'll output rego. So I'm also working on trying to get system scoping, even though that's still not a thing in OpenStack. But I'm working on it to get it there. But still, I mean, you can still use the old ways to scope just with OPA, right? So finally, when you get your rego file, you can just run it maybe in your sidecar container or as part of a system demo or something like that. But I mean, you already have these rules that you can configure in different ways, right? Actually, OPA allows you to pull from a bundle so you can push rules to it or you can pull rules from it. So if you're running OPA and configure it to pull from a centralized repo, you can do that. So you get centralized login, right? Or you can just pass it like you would with your regular Oslo Policy. But all right, so what's next? I'm not really presenting the whole thing right now, but I mean, this is work in progress, like I said, performance. So while OPA rego is very performant, it's still not the same as having your in-memory cached rules from Oslo Policy, right? You do get some header from doing your HTTP requests, going through the network, even if it goes to local host. So you are going to have overhead. Also, while it's quite trivial to bundle your rules in a centralized repo, that doesn't really give you the version control or being able to roll back. So we still need to write a small server that does centralized policy and does handle versioning and rolling back and whatnot. So that is yet to be done. And finally, of course, in able to get this work done, even though I did this more or less in my free time, we need interest from people, right? So if you're interested in it, please mention in the reviews, please give me a call. And if you're a client for Red Hat, contact your representative and tell them we need this done. So we can get more time to work on this kind of stuff. So if you're interested, the GitHub repo for the tool is there. I also wrote a blog post where I actually mentioned how do you translate directly and manually from the regular language towards Oslo Policy and vice versa. So that's there. And yeah, do I have time for questions? Yes, three minutes. Any questions? It was 10 minutes, so I went too fast. Right, so OPA is just the agent, right? And you can definitely run that as a sidecar. Actually, a lot of projects in Kubernetes run OPA as a sidecar for their service. So let's say you have Keystone, it would run in the same pod as Keystone itself. Barbican in the same pod as Barbican. But it's also possible to just have OPA as part of its own container. And then the service is just pulling the OPA inside the same host. You are going to have that issue anyway if you want any sort of centralized policy unless you decide to just not pull and have a system that pushes in the required changes. And you can do that as well. You don't need to use the bundle service that OPA offers. So that would be another option. Anybody else? Thank you.