1:00 Introductions

1:24 Hello, and welcome to today's episode of Rawkode Live. I am your host, Rawkode. Today, we are gonna be taking a look at Policy Reporter. It is an open source software for hooking up the policy reports from Kivernal to other pieces of other pieces of software to your monitoring systems so that you can get better visibility into the policy violations and audits within your cluster. Before we get started, this is a little bit of housekeeping. So first, please, subscribe to the YouTube channel and click the bell. This just means that you will get notifications on future episodes of Rawkode live as well

1:31 Introduction to Policy Reporter

2:00 as helping other people discover this content as well. There's also a Discord server. Feel free to join in there and bring all of your questions. We are active pretty much around the clock at the moment. So, you know, even if I'm not streaming live, there's still lots to learn and share with other people. And lastly, I wanna thank my employer, Equinix Medal. They provide the time and resources that I get to invest in their shows and produce cloud native learning materials so that we can all learn together. So thank you very much Equinix Medal. Feel

2:33 free to check it out. There is a quote there for 50 US dollars. This is around one hundred hours of compute of bare metal clouds. Lots of fun to be had. Enjoy it wisely. Okay. So we're gonna take a look at Policy Reporter, and today, I am joined by its creator, Frank Jobolete. Hey, Frank. How are you? Hi, everyone. Frank's fine. And you? Yes. I'm very well. I'm very excited to kinda take a look at Policy Reporter today, and I'm really happy that you were able to join me. Yeah. Thanks for having me. Yeah. Do you

2:44 Introducing the Creator

3:05 wanna just start with a little bit of a introduction to yourself, and then we'll talk about Policy Reporter just after. Sure. I'm Frank in German. Frank j in the, yeah, communities because it's much easier to say. Yeah. How I say, I'm from Germany, from the New York Dresden. I'm working as software developer for Move Elevator. We are a company creating custom applications for our clients, mainly with PHP, Vue. Js, and, yeah, the old, good web stack. And, yeah, I started with Kubernetes and the cloud stuff for a year, And I really like the community. It's

3:58 very cool to work with other people. And so I'm today part of the Fackle community as well as Hiverno. And, yeah, I'm in the Rawkode chat every day as well as the CNCN show. Awesome. Thank you very much for sharing that with us. So today, we're taking a look at policy policy reporter. I I was gonna say your latest open source project, but I don't know like how many of these you just have lying around. But Policy Reporter is is a really cool project that we've been talking about a lot on a Discord server and

4:20 What is Policy Reporter?

4:33 you you're shipping updates so fast that it's just amazing to watch that evolve over time. But why don't we take it back a little bit and you just tell us, like, what is the primary responsibility of your project policy reporter? The main goal is to get a better visibility of what happens with your Kiverno policies. So I use Kiverno to enforce more best practices. But it's really hard to enforce everything because a developer's stuck. They have no no not much experience with Kubernetes. They don't know how to do things. So I thought it's better to audit these violations

5:18 and have, in the later point in time, a look at it. But, yeah, this was not that easy because you only have this CLE CRD commands to see what's going wrong. Then it's across the complete cluster with many different namespaces. And, yeah, it's was not that easy. And so I thought it's a good idea to create a tool for this. I'm part of a FARGO community. In FARGO, we have a tool called FARGO Sidekick. And FARGO Sidekick UI, it's very similar. You have a UI where your violations from Fireco are displayed. You have a table to

6:03 filter, sort, and so on. And, yeah, I translate this into Kaverner. And so Policy Reporter was born. Awesome. So I think that's a really common story that, you know, I hear when I'm speaking to people in the cloud native ecosystem is that they want to adopt, you know, tools like Kiverrnal and open policy agent and all of these best practices. But at the same time, you know, the platform teams and the SRE teams want their developers to be as productive as possible, especially with learning all of these new technologies as well. So moving and having

6:37 policies run-in audit mode rather than force mode, I think is is extremely common. I think what you articulated well there is that you you gotta do something with those audit logs, and that's where Policy Reporter comes in. It gives us the ability to hook it up to our existing tooling like Prometheus and Loki, and we'll take a look at this on the hands on bit. But just making sure that they're not lost in the abyss, the noise or the migrations or all those other things that we have surrounded us all the time. So very, very We

7:06 Policy Reporter vs. Other Tools

7:06 have a question now from Carlos. Carlos is curious of how does this compare to other solutions that are pros and cons? Is there anything similar to Policy Reporter out there at the moment? I don't know other tools for Kivera, especially. I don't know if there is anything else in the OPA community. I'm not sure about the products from the as a company behind. I think if so, the main difference would be that it's not a platform or any byte solution. It's open source tool to install, to debug your policies. You can try what is affected.

7:55 And if you don't need it anymore because you're in a production environment, you can remove it easily. So, yeah, it's a small small application, I think. Okay. Let's touch on one of other Carlos's questions just before we we kinda move on a little bit here. So Carlos says, they're a little confused. Is it Falco versus Kiverna? I'm gonna assume you would run both, but do you wanna just give me your thoughts on that? Yeah. I'm running both. Security in Kubernetes has more than one layer. You have runtime things. You have money manifest validation. And, yeah, Faggle is security

8:09 Understanding Falco and Kiverno

8:37 at runtime. It tracks if you SSH in a node. If you change a file in a it's a c it its directory or in the root system, it affects all this this time on runtime. And, yeah, you can also alert track track or alerts and other applications. But Kavana is for static validation, I think. So more you if you have resources defined in your manifest, if you don't use latest, all these things, it's related to port security policies where you try to remove host paths, host ports, these things. So it's another level of security, I think. It's Oh,

9:31 yes. Best differentiation. Yeah. I couldn't agree more. I think Falco fits into that space. Like you said, runtime security is monitoring syscalls on the kernel and alerting you when things are doing things that you maybe don't want them to do. Kiverrno and open policy agent on the other side, they're taking a look more at the declaration or the manifest that we're applying to our cluster and making sure that they conform to the constraints that we apply as well. And we'll see that, you know, we've we've got, well, not a cluster. I have a Docker for

9:56 Hands-on Setup

10:01 Mac, which has got a Kubernetes API where I have deployed Kiverno. I think what we can we can do to start with is maybe just take a look at the pod security policy replacement policies from Kiverrno. I can't remember if it ships with a default report, but maybe we can look at that and and actually see the problem. Right? Is that Kiverrno does expose some of this information, but not in a way that is consumable by other tooling. And then then we can move move into Policy Reporter. How does that sound to you, Frank? Yep. Makes sense. Awesome.

10:31 Alright. Let's get my screen share up. So for anyone who wants to follow along or is watching this not in real time, you can find Policy Reporter, Frank's GitHub username slash policy dash reporter. Nice. Now what if I go prepared upfront? Very, very little. I have Docker for Mac running. I have deployed Kiverno. I've got Kip Prometheus deployed as per Frank's request. Oh, no. My note export is broken. Although that probably wouldn't work in Docker for Mac, so that's okay. Which gives us a Prometheus operator, a Grafana, and a Prometheus instance. So pretty much all the tools that we

11:00 Installing Policy Reporter

11:15 wanna kinda hook into and and show what's happening. So what's the best way for someone new to Policy Reporter to get started? Do you want me to pop open the docs, or do you wanna just go off script? What what are you thinking? I think the easiest thought is with the policy report UI. It's yeah. You add the repo as available as hand chart, so it's very easy to install it. Then, yeah, you have this basic installation be but this is only the metrics for Grafana, so you need an existing monitoring to use this. So the, yeah, way easier part would be

11:19 Installing the Policy Reporter UI (Helm)

11:58 the second installation where you enable the UI and have a standalone UI UI where you can start from. Okay. So I can just copy and paste this helm install command that sets the value to true for the UI deployment, and I'm still gonna get the Prometheus exposition. Is is that correct? Yeah. You the the parameters metrics are default, so they're always enabled. With the UI enabled, you get a second application's UI. So it's not backed into the Policy Reporter. It's standalone application which works over a REST API policy reporter. And you can access UI over

12:46 port forward. Alright. Perfect. Okay. So I've added your Helm repository. I'm now doing the Policy Reporter installation with the UI enabled, and then I'm gonna copy and paste the port forward, which I'm assuming is just gonna take me straight in to the UI if I knew how to copy and paste. There we go. Yeah. Alright. So okay. So it's just pulling some images right now. We'll give that just a few seconds We'll get started. Let's see. Why are you pending? Oh, no. There we go. Just me being impatient. So this is pro forward into 8082.

13:20 Policy Reporter UI

13:39 Ta da. Easy. Yeah. Love it I love it when things are just, you know, helm repository at helm install. Like, job is done. There you go. There's your next UI. Oh, look at material and shiny. Very, very cool. Hamstrap reduce reduce the effort to get started because it's, you know, has all this default URLs, ports, and so on. So it's all configured for you behind. And, yeah, you see your first violations for the monitoring ports because, you know, they has host paths and host namespace configured, which is not allowed with the PSP policy no. Pod security policies, so to say.

14:29 Okay. So an issue I what I'm seeing is just how many policy violations we have. We've got a kind of graph here. So I'm assuming if we fix any of these, if we can fix any of them, we'll start to see this drop. We've got failing cluster policies. Yeah. What's the difference here? Is that The the dashboard is a overlook of failing resources, so you don't see any passes because it's a, you know, short introduction. And the main diff or the the only difference besides policy report and the cluster policy report is that the cluster policy report

15:07 is only for resources that are cluster scoped, like namespaces. Got it. So they have its own CID in Kiverno and also in the policy report standard. And so it's a yeah. It's different. Okay. So should I click on policy reports? Should I click on one of these things? What do wanna look at? Yeah. If you click on any of these labels, it's only a filter for the table. So you have a search field so you can easily filter for a specific policy or rule or severity if supported. And I think you can go to the

15:50 policy reports. There is a more detailed use only for the policy report CID. So at first, you don't see any violations because you have a default filter for a single policy at the beginning. But you can open this select field, and you should have option for all policies. So you can define what you were looking for if you would like to see any violations or for a single policy or for a set of policies. And if you like, you have also a optional filter on the right side for only a namespace. So you can also recreate the view

16:34 of a single report for a single namespace if you like. It's Yeah. On you. I I think I prefer looking at the sea of green passes rather than my three failing policies. At at least we can see here what what's happening and how the policies are being used and consumed, which is I think just exposing more of this information in an official way is really important for people to understand what is happening and and just get more comfortable using tools like this. Yeah. Standard for policy reports has two more status codes, and they also have error and warning.

17:12 But at this time only has passed and failed violations. If our feature future tools also use the CRD like, they have this additional status codes, you will all also see additional tables for status codes. So it's high the UI hide automatically all tables and charts without any value. Okay. So I just wanna understand then, like, you know, we've deployed Policy Reporter and the UI. They're two separate deployments, two separate pieces of software. Is the Policy Reporter UI just creating Kubernetes API for the Kivernal reports, or is it going through Policy Reporter in the middle? Like, how how does this actually

18:03 work? It's working with the Policy Reporter together. Policy Reporter fetches over the Kubernetes API the CRDs and convert them in the one side into parameters metrics and the other side in a custom structure, which also available as REST API. So the Policy Reporter has a REST API, which you can also use with your own tools. The UI is not required. They are open and also available endpoint. And UI use this REST API from the policy reported UI Policy Reporter and has a proxy back end because if you put forward your Policy Reporter UI, you need access to the

18:57 API it's fetching from. So you can only fetch from the back end from the Policy Reporter UI, and so you need some API in the middle. But this API fetches information from the Policy Reporter and forward it to the UI itself. Alright. Very cool. We have a question from Walid who is asking, can I monitor the audited policies only? And then a little bit of a follow-up is, like, audit events not enforced. Maybe we could just explain the difference between Kivernal policies with enforced mode and audit mode and what that actually means as well. You

19:15 Policy Modes (Audit vs. Enforce)

19:35 wanna dive into that? Sure. Audit events don't affect you if you apply any manifests. It's creating this policy report in the background, and you can access this information when anything violates. If you have an enforced mode, it blocks you from applying this manifest. So you the the kubectl will return an error with the message from your policy. And, yeah, you have to fix the manifest before you can apply it to a cluster. Kavura offers configuration in your policies, the background. Background has well, background is used to validate existing resources. When you apply a new policy in an enforced mode, you enforce new

20:29 manifests. It has no don't it's used for existing resources. So with the background enabled, it also scans existing resources and creates a report for it. So if you apply an enforce policy with the background scan enabled, you also get the report for this policy, and you also see the result for these policies in the UI. So you can also track the violations for existing resources. Okay. Slight segue then. I'm assuming you run this in your production Kubernetes environment? Yeah. How I say I'm using Kubernetes in my free time as a hobby project. We introduced Kubernetes in my company

21:24 a few weeks ago and created our first playground Kubernetes. But we don't have any production applications running on cloud services? Not yet. That day is coming. Not yet. Yeah. I am working on it. Yeah. Okay. I'll just I guess, we'll you know, we can kinda speak hypothetically then. But I'm I'm gonna assume that it's okay to have policies that are failing and be aware of it rather than having policies not enforced at all. I can imagine, especially maybe in my own production environments, is it as the goal to have zero failing policies, or is it just to

22:07 keep that number going down? Do you get any opinions on that? I don't think that you have to fix all issues. Sometimes you can't really fix it because maybe it's an application you installed with Helm, and you don't have access to this configuration. Maybe you have tools. They need this host path, for example Yeah. To work with. LongHorn as storage application or fleet or something like this. So you can't fix everything. I use it as best practices. So it's good if they pass, but it's not required. And maybe you create a policy to get some information about your

22:56 environment. Maybe you want to know which pod's running with the latest image. So you can create a policy. You can set to audit mode, apply it, see the result, and remove it instantly. So it's also a tool to get any information you want from your cluster. Alright. Thank you. Okay. Is there anything else you wanna look at in the UI before we move on to other best NPCs? You can click on locks, but I don't know if there are no. Not Yeah. My local cluster may not really have much going on. Yeah. It's the locks are coming when you deploy

23:38 violations after the UI started. So you started the UI right now. So there was no new workload, so it didn't work. But we can also see this maybe later on when we did some stuff. Yeah. So we've got some default policies installed. I'm sure we can definitely violate a couple of them and see those logs coming in. Why don't we take a look? You know, we've got all of this deployed to the to the cluster with Prometheus and Grafana. So can we walk through the process and the steps involved for, you know, maybe bells on out my own

24:00 Integrating with Prometheus and Grafana

24:13 little dashboard here? Yeah. To getting started with Grafana. Yeah. So you said that policy report are running in the cluster. It takes all of the policy reports from Kiverno and produces Prometheus metrics. So I'm assuming the first thing we wanna do is is make sure that those are being consumed by the Prometheus and our our Kubernetes environment. Yes. Yeah. You can when you're running with Prometheus operator, you can use optional monitoring sub chart of Policy Reporter. It provides you a service monitor, a CID for this operator to scrape the metrics, and it provides also configurable

25:07 dashboards for Grafana, if you like. So to running the installed version of your operator, you have to I don't know if it's good to do it over the CLI. Maybe the values YAML is better in this case because we have to configure a few things. Yeah. You're right. Okay. So where is that first one? So we enabled UI dot enabled. That's all so far. So why don't we do I think I created a YAML. There we go. Oh, that's the Cavernon YAML. Okay. Alright. So UI enabled. True. This is always done so far, I believe. Yeah. Yeah. Okay.

25:57 What this other command you've got here from the documentation is saying is that we can turn on monitoring dot enabled and then provide a name space. Yeah. You need to enable the monitoring. That's enabled part of the name space. When you're using this prometheus operator, you have to install the config maps, which include the configuration for the Grafana dashboards in the same name space as Grafana. So that's why you need to declare namespace where the Grafana lives in. Okay. So where is my I think it's just in monitoring. Yeah. So So, yeah. You define it as monitoring.

26:48 And I've got like there. It's happy now. Nice. Is there anything else we should tweak now before we do an upgrade just so that we have it available? Yeah. You have to add a service monitor label. I think it's was right over the commands when you see the description with monitoring service monitor dot labels. Yep. Yeah. This part. So I am using Ranger, and Ranger has included preconfigured monitoring system, which is built on top of the Prometheus operator. In this case, you don't set this label because Prometheus looks over all namespaces. In this installation, in this custom installation, you need to declare

27:44 a label for the service monitor. So the Prometheus resource, yeah, scrapes the service monitor. That's why we need to define it in this case. Okay. So we need to define service monitor. Okay. So what label is this looking for? I think the default one would be release and the name of your Should I just describe the Prometheus operator? Is that? Yeah. You need to describe the Prometheus resource. So not the pod, but the Prometheus CRD. Ah, yes. Yes. Okay. So let's do a get Prometheus. Describe Prometheus, this one. And there should be a label on here that we wanna target.

28:51 Yes. Service monitor selector on the bottom. Got it. Okay. I'm assuming this is maybe just a map then rather than a Yeah. Less. Does the case matter? I'm not sure, but I think it's lower case. In my installation, I use lower case. This is pop up. Yeah. Lowercase. Weird that it's capitalized. Must be something to do with that output. I'm gonna ignore it for now. But, yeah, let's go with lowercase. So our values fail for the policy reporter deployment has monitoring enabled. Service monitor should be under monitoring, not on the same syntax. Yeah. See? It's always good to have a second

29:42 set of eyes on these things. Okay. Monitors enabled. We've pointed it to the correct namespace, and we've added the service monitor from the Prometheus CRD. Means I should be able to do a helm upgrade policy reporter policy reporter. We don't need any of the sets nor the create thingy, but I will need the namespace one. Does that look? Do you need to set the values, Yandian? Yes. Alright. Yeah. I think that was okay. I think this should work. I hope it will. We're both just ringing with confidence here, but we've got revision two, so I'm gonna take

30:34 that as a win. So I'm assuming at our policy reporter namespace, we should see oh, wait. We see I don't see that it should update the Policy Reporter because it doesn't change it. You only apply more resources for the operator. That's right. Because we're deploying a service monitor. Maybe not oh, yeah. There we go. Yeah. So should we pop open the Prometheus and see if we have any metrics? You can show it in Prometheus or later on in Grafana. Yeah. Let's take a look at the the Prometheus first and then we'll see if we can get well, we

31:22 will. Confidence. We will get Gafana hooked up. But I always like to test at the source first. So in theory, if we go to target, I think that's okay. Do we have any policy? Hey, look at that. Yep. Nice. Which means we should have access to a graph. There we go. So I'm not sure what this search for policy. Policy. Yeah. Policy report results, summary. I'm gonna execute. And we have loads of metrics. Awesome. Yeah. But, of course, we do not encourage people to use the Prometheus baked in UI. This is where Grafana really shines.

32:19 That's right. Yeah. Alright. You mentioned sorry. On you go. What? No. Continue. Okay. It's just crazy. I mean, you mentioned something really cool earlier on in the episode is that there are pre canned dashboards that are shipped for us. So let's can I just put forward to Grafana and we walk through the process again those hooked up? Sure. Yeah. Alright. Let's see. Port forward. 3,000. Okay. We have Grafana. But I'm gonna ask if my dashboard isn't here already. Right? They should already available. Alright. Give it a refresh, see if it helps. Oh, it does not appear happy with me

32:21 Exploring Grafana Dashboards

33:32 at all, does it? Now I have to decide, am I being impatient or is it broken? Let's try one more time. Strange. Okay. So we have our dashboard home. Yeah. You should click home on the yeah. And there you already see policy reports or label. So you can also in your list, in the first entry, yeah, can click on it and you should get three dashboards. So they all very similar to the dashboards you saw in the UI. So they provide similar informations, but in a better scope in Grafana. So is that something that the Prometheus

34:32 the Kube Prometheus project is is doing? How did you get those Grafana dashboards into my Grafana? Yeah. The operator supports config maps to define dashboards. And what I did is I built these dashboards in my own Grafana and export them. I replaced some informations with dynamic variables you can configure in the Helm chart. So as I said, you have some status codes like warning and error. They are not supported yet. So but I would like to support the CRD complete. So I add them to the dashboards, but I added Helm values to disable them or hide them in this

35:25 case. And, yeah, the sub chart includes this config maps and add them to your Grafana namespace. And so they picked up from Grafana and available. That's a nice a nice touch. I like that. Alright. What one do wanna pop open first then? Yeah. I think you will see the most You can do the third one, the policy reports. So that's it's a complete overview as you saw in the UI. Yeah. You have all tables currently also without items. You can well, in you should see tables with results, but maybe not. Yeah. I'm not sure. I mean,

36:21 if I was oh, there we go. I was gonna I was gonna say, if I was better at my job here, then I would have deployed all of this much earlier so we had retro data to capture. But miraculously, it just popped right on there, so that's pretty cool. Well, our confana did take the attempts to load the homepage. So something tells me there's a maybe there's something going on with the communication back to my Docker for Mac. But but it doesn't matter. It's possible. Okay. So we got our we can see how many policies we have failing. We got

36:57 the cluster policies. These two very similar to what were available in the policy report or UI. We then actually have some time series here where we're seeing the count of failing policies over time grouped by the policy that had the failure, which is a very nice one to chart. I could imagine in real production clusters where there's a vast array of policies being audited and enforced, that single graph alone is gonna be really, really interesting for anybody, I would imagine. Yeah. And that's a graph that I can't provide in the Policy Reporter UI because then

37:34 I need the complete history of all violations. So that's, I think Yeah. This is classic classic time series now. Like, you you need a TSDB for it. You need that available. That makes a lot of sense. And then we have a table just down the bottom. I think it's just showing pretty much the same thing as the graph. And we have no cluster policies, so that's to be expected. Should we pop open the other two? You can also see the policy report details. Yeah. Cluster policy don't show anything because we don't have any cluster policy. So I think we can skip

38:14 it. Yep. We got the namespace breakdown, and we got another little time series graph. And I think these aren't loading just because of my whatever's going on with my network. Yeah. And in this dashboard, you also see currently the status and the arrows status chart without any value. But if you dive more into the configuration purpose of this monitoring chart, you could be you could be enable disable this this parts of the dashboard if you don't need it. Yeah. I mean, I think this this alone is the main reason why everybody running Kivernal and their clusters just needs to have Policy Reporter

39:00 available to it. Like, you know, I think every I think it's really safe to see every operational team out there in the world probably has a Grafana instance running in their cluster with Prometheus. Like, they want again, I'm not gonna put words in everybody's nose. I want to use the same tooling across my stack. And I think this is just really super cool. Yeah. Because once I have it all here and I have my dashboards, you know, the entire team has visibility into it. But I also have the ability to then build my alerting on top of it. There may be some

39:30 policies that although I have an audit mode due to migration issues, probably wanna notify somebody quickly. I mean, I can imagine there are some that I would deem probably a security risk. Although, maybe I should just enforce them. I don't know. I'll talk myself out of that one at some time. Yeah. For alerting and notification purposes, the second main part of the policy reporter, which was the initial idea behind it to send notifications when any violations happen to tools like Loki, Elasticsearch. It also has support for Microsoft Teams and Slack. So, yeah, only with Policy Reporter and any chat

39:52 Notifications and Policy Priorities

40:18 client you use, you can also notification send notifications to it. Okay. So back and send notifications to Slack and Discord, I guess, to any HTTP point, really, as long as I just connect it up. Yeah. And if your chat client is not available yet, you can, at any time, create an issue or develop it yourself and create a p p effort. Yeah. I love that. Pill request welcome always. Yeah. Is there anything else you would like to to show if I forgotten anything? One part which we don't cover because it's only related to this notification

41:06 things are priorities. So for Loki, I created, yeah, a priority to violations because the policies pass or fail. So if you have a failed one, maybe you differentiate between that's not that important, that's very important, that's disaster. And so I integrated a mechanism to define what's how important your policy is. Per default, you create it creates a priority of warning for a policy. But you have the possibility also over the helm chart to create a mapping between policy name and the priority. And so you can switch between a info policy, running policy, critical policy. You have a special key for a default.

42:11 So if you like to default all policies to info, you can also do that with one configuration and, yeah, configure how you like it. And in Loki, you have different colors and, yeah, your alerting tools will stick on these priorities. Oh, nice. Very cool feature. I opened an issue and also a PR to Kiverno for configure severity to policies, which is CRD way currently to define between low, medium, and high. And if this feature will be available in Kiverno, it use this information also to map your priority between info, warning, and critical. So you get two ways, the Policy Reporter

43:09 way and the more native Policy Calverno way. Yeah. That makes a lot of sense. So you said you've opened that as your conversations are happening, and maybe that's something we'll see in a a future release of Caverno. Right? Yeah. It's scheduled for January, I think. Sweet. Awesome. So what's next for Policy Reporter then? Do you have any other, you know, features, ideas, pencils, under your head that you're you're gonna bring to us soon? At first, I have a look if any other tools will implement the CRDs, like, already mentioned. And if so, have a look if it worked as expected

43:34 Future of Policy Reporter

43:58 or if there are any differences I have to change in the Policy Reporter to also work with these tools. The second part will be more Kiverno specific. Currently, Kiverno works on its own metrics with more informations I can provide because they yeah. Kyverno internal. And if they will be available, I want to integrate them into the UI as as module, I think. So you don't only have the CRD global metrics, but also more detailed one for specific tools that work with the CRDs. But this this depends on the metrics for Kaverno and when they are available and so on.

44:51 But I will have a look, an eye on it. So k. Alright. Is there anything else you want to cover before I let you get back to your day? I would say thank you also to the Rawkode community because the idea was born also in an episode with you and the team. Yeah. I really thank the community for supporting me by answer questions, help me with policies, and so on. And, yeah, also Adrian and the CNCN community who also helped me a lot and promoted my small first version of Reporter in its show. Yeah. I think that's one of the the

45:05 Community & Closing

45:46 great things about the communities that, you know, we're working with here, the cloud native and Kubernetes and policies and. Like, we all just want each other to succeed, and the amount of support across the board I think is phenomenal and always welcome to And I'll just say thank you to you. You know, you're the one that has invested your time and energy into giving us better tooling to get those really critical metrics out of Kiverno and to those tools we're familiar with and you're even going above and beyond to provide like your own UI and stuff like

46:15 that. So thank you very much, Frank. It's a really cool project and I I hope a lot more people will check it out and make their lives that little bit better. I hope so. Thank you very much for having me. Alright. Well, you have a great day. Thanks. I'll speak to you at the Discord. Everyone else, I'll speak to you soon. Yeah. Thank you everyone for watching. Bye. Bye. Bye.