 Welcome to Cloud Native Live, where we dive into the code behind Cloud Native. I'm your host today. My name is Whitney Lee. I'm a CNC app ambassador and I'm a developer advocate at VMware Tanzu. So as you may know, every week we bring new presenters to showcase how to work with Cloud Native technologies. We will build things, we will break things, and we'll answer your questions. Today we have Stephie Janis here with us to talk about how to supercharge your infrastructure management with Open Policy Agent. So just a reminder, this is an official live stream of the CNC app. So as such, it is subject to the CNC app code of conduct. So that means please don't add anything to the chats that would be in violation of that code of conduct. So be nice, be respectful of the other folks in the chat, be respectful of Stephie the presenter, and be respectful to me too, please. I'd appreciate that. Friends who are joining us live, please do say hi in the chat right now. Tell us where you're tuning in from. I love seeing it. I will be able to shout it out, but I do watch it and I love to know that people all over the globe are watching, are here with us right now. It's so amazing. So as always, if you have questions during the presentation, go ahead and put them in chat. Today we're not going to answer them right when you have them, we're going to save them for the end and then we'll do a Q&A part after Stephie's presentation. So with that, I'm going to hand it over to Stephie Giannis to kick off today's presentation. Great. Thank you very much for having me with me. It's amazing to be here again. So I'm Stephie Giannis and I'm the CTO and co-founder of Firefly. Today I'm going to talk about open policy agents, and I'll elaborate and explain why we need this. Before we begin, I'd like to explain a bit about my company, about Firefly. We built the first Cloud Asset Management Platform that reduced the Cloud complexity using infrastructure as code. What we do in Firefly is to scan the entire Cloud footprint. I mean, hyperscalers like AWS, Azure, Google, etc. We analyze also Kubernetes and SaaS applications, and Firefly analyzes also the infrastructure as code. All I see tools from Terraform, CloudFormation, and even Helm charts, etc. We continuously detect the discrepancy between the Cloud and the IAC. We can generate Terraform code, or IAC code, using AI for something that was created manually. We detect drifts and unexpected changes because we are integrated with the Cloud events. And we also govern the Cloud using Open Policy Agents. And that's why I decided to talk about this subject today. Great. So go ahead, Sydney. Oh, nothing, I'm just excited. Cool. So let's begin. And I would like to explain what is OPA and why do we need this? So Open Policy Agents is the first unified policy as code solution with the language called Breville, the clarity language called Breville. The idea behind the OPA is that we can check, we can build any rule that we want and check on the JSON file. I mean, if I have a list of people, and right now I'm building a rule to detect who is more than 30, I can detect from the list of the people exactly I can get the result. And in this session, I will show you many examples for Kubernetes, for AWS, et cetera. In general speaking, you can see Open Policy Agent, that's a mature, open source tool, also approved by CNCF, and many companies out there adapted this great open source tool for many other purposes. I told you about Firefly, that we adapted OPA for governing the cloud, for secops, they have a real ability, et cetera. But out there, there are solutions for authentication and authorization that they utilize OPA for this purpose. Or for network firewall rules. For example, we can detect if a network is allowed or denied, et cetera. So I would like to share a screen and start with a quick example. Thank you, Whitney, for that. Okay. So I brought here an example for a rule, as you can see, that check if we have someone that is older than 20. And of course that I will elaborate and explain exactly the structure of this rule. And I have two people, I have John Doe and Michael Smith. John Doe, you can see he's age is 30 and OPA is OPA and OPA Kubernetes, and Michael Smith is 18 and OPAs are serverless. So let's take the OPA rule that I've created here. And I would like to introduce you to the OPA Playground. I'm John and I'm sharing this screen. Okay, the OPA Playground, that's a great way to detect our rule, to analyze, to assess if we build our rule correctly. So I'm taking the OPA Regal rule here. Now let's take the two JSON files and I would like to show you the result. Or John Doe, you can see that it's valid equal to true. And for Michael Smith, you will see the negative, I mean valid equal to false. Great, let's talk about the structure here. You can see that in Open Policy Agent, I started with the package. Package means what I'm going to run. And then I built here a default variable called valid, that the default value is false and I override the default value if the age is more than 20. So that's a simple rule for that. And we can, and I will show you in this session may complicated rules for many purposes. But let's dive more technically and if somebody here has some questions or would like you to repeat or something that feel free to write on the chat. Cool, so first thing, I would run right now the OPA server and let me zoom in this. You can see that I'm running a Docker run file. Docker run for a port 8181. The server is already running. So one, let me run it again. But it's very easy to run OPA server. On top of that, we will add our regular rules because we will add more and more and more policies. And after running the OPA server, after loading the OPA rules, we would like to check JSON files for each rule to understand if a rules, if a JSON file is complied or not compliant. So here, and I will explain what we have here. I'm loading the first OPA rule. You can see that I have file called example Revo that that's exactly what I showed you on the left side. And then running a command to HTTP put to load the data from the example into the open policy agent, let's run it. Now you can see that it's loaded. And I will check right now John Smith and Michael Smith and John Doe. So the first one, you can see valid through. You can zoom in. So trust me that that's the result. The second one is a valid false and we run right now the OPA server on our local machine and I show you this because it will lead me, it will help me run the second parts of this talk. So just to explain, I'm reading the JSON file of each user, John Doe or Michael Smith and then I wrap the JSON file with input and I'm taking this and sending HTTP post for the OPA server. And then I'm folding the wrapped JSON and then I'm getting the result. So that's how it works. Super. Before continuing to the second part of this talk, does anyone have questions? I have a quick question. So policy seems really powerful. And so if you're trying to start policy into your whole system from scratch, that seems like maybe kind of a dangerous undertaking or something you need to do very delicately. So do you have advice around how to start if you don't have any policy right now, like how to, what you would do as your first like baby steps into getting it working? Yes, of course. First, we need to understand the data because here I built it to users and in the next phase of this talk, I will show you a real example from AWS or Kubernetes. So we need to understand the data and then let me show you the regular playground. So you can see that they always search input dot age, input dot something, dot something because I needed to deep dive into the JSON and this JSON object might be complicated. Here, for example, I have hobbies list of something, but if I would like to see if I have at least one hobby that contains a prerequest of the world, we need to dive into it, okay? Excellent. Super. Great, so we think I would like to continue with the second part of this talk and now I will show you more example, real life example for Kubernetes, for AWS, et cetera. Let's start with Kubernetes, CNCF, I know that most of the people here love Kubernetes. So what I did here is to take a Kubernetes deployment, I logged into my Cube CTL and run Cube CTL to get the configuration of the specific deployment. You can do it also with the lens, for instance. And as you can see, I have a JSON file and I will show you this soon with the deployment itself. Let's copy the JSON here. And a build for you two different rules, one for detecting CPU requests that all deployments contain the CPU request, mandatory CPU request, and the second one, readiness to a probe. Because I understand that that's important policy. So let's copy the readiness probe and let's place it here in the lab right on the rule and let's evaluate and you'll see here the result. In that case, it's not allowed. And if you need to dive into the rule itself, you can see that I'm using something that was created by the community. I'm importing a library. And if I'm going through this, you will see under Open Policy Agents, the library itself. And I don't recommend to use pre-created libraries. So we have here the default variable allow, starting with false and then I built here a function to detect if I have a readiness probe. As you can see, it runs through the configuration that they have in that case. If the deployment has a spec.template.spec.containers, this sign is really important for you to understand what is that because I might have a list of containers. And if I would like to check if at least one of the containers inside has readiness probe, so I need to use this sign. And in the end of the day, I run the rule here and I'm getting the results and the same also for the CPU quest. This one is an easier one, but let's use it. So you can see that I'm also importing a library that was created by the community. And I added here value equal to one for a default CPU request. And then I deep dive into the configuration and the policy that returns if the deployment has CPU request or not, if I'm running this, I get the result. And one of the pains that we face with is to write the rules. And you asked me a great question before. And I can tell you that I spent hours for building rules. That's why I really recommend to utilize AI to generate the rules for you. Yeah, and in the last session that I had here about AI AC, the open source tool that we have created at Firefly, I showed some examples for infrastructure as code. What I'm going to show you right now is that you can use AI AC, AI tool to generate the policies for you. So what you need to do, A, you should go to open AI, generate an API key. As you can see here under the platform, you can go to the settings, APIs and generate a new key. And then you need to add the API key into the terminal. It looks like that. I'm gonna ask you to slow down just a little bit. People, when you were doing the playground earlier, we got the question, will you be sharing the samples? So the examples you gave of OPA before we even got into AI. Can we see those examples or is there a way for people to access those later to try them out for themselves? Yeah, I will upload everything into a dedicated guide and I will try it with you, okay? Okay, so great. And then another question is, can you share the library again? The library, you mean this one, the AI AC? Maybe so, we zoom in on that so people can see what it is or share the link in the private chat. Let me elaborate, please, because everything that I've used here, all the rules that you hear, they are available for free for your firefly. I mean, what you need to do is to go to a firefly.ai. You can sign up for free and that will show you all of the rules. Under the policies and insights, we built many rules for you, for Phenops, SecOps, Relability, for AWS, Kubernetes, SAS application, et cetera. So if right now you would like to see a rule for Kubernetes deployment without CPU requests or CPU limits, you can see here the OPA rule and you can just sign up for free and use our platform. So enjoy for me. Yeah, we need to have any more, any other question or I can continue? Please continue. Some folks are asking the Zoom, so you're doing, I think, a pretty good job of being mindful of making sure that font isn't too small. Yeah. But just something to watch. Sure. Cool folks. So what I wanted to show you is AIAC, our first open source tool that actually generates infrastructures called or policy or whatever you want using AI. So I started with OpenAI that you need to generate the API key for OpenAI. And then I will give you a real example for policy. Let's copy this. AIAC gets OPA policy that enforces readiness probe at Kubernetes deployment. Now I will go back to the CLI. It's a bit hard to zoom in, so I'll copy to the text on the top. So I'm running the AIAC. Now it's generating this rule with AI. Takes a couple of seconds. And then you will see the rule that was generated by AI. You can see here the rule itself. And you can use it. OK. So you can see that this rule was fully generated by AI and that's the example that I showed you before. So what you can do is to run the CLI command for AIAC and then you can use an argument for output file. I mean, to save the generated AI policy to a dedicated file and then you can utilize this. I mean, you can add the policy to the OPA server and then you can run any configuration that you want to detect the policy. So before continuing, I just want to conclude this specific part. I'll show you some examples for Kubernetes. We took a configuration of the deployment and then we built two rules. Doesn't matter if we built it with AI or we just wrote the policy for you. But in the end of the day, I wanted to check if my Kubernetes deployment complies with those policies. Now I'm going to elaborate on AWS because here I brought a lot of examples for FinOps, for SecOps, for Adability, et cetera. So the first thing that we need to do is to scan the cloud. And this is not so easy because, as you know, in AWS specifically, you have more than 20 regions. So you need to walk through all regions and run the CLI command to list your EC2 instances. So what I did here is just an example and I will explain how we can actually do an automation for that. So I'm running the EC2 describe instances and I will show you the command here. One second. EC2 describe instances, minus, minus profile, minus, minus region. And then I'm getting a result. I'm getting a list of all my instances. I'm doing the same for volumes and for lambda function and I save each of them in a dedicated file. Instances or a lambdas or whatever it is. Then I built many rules and I will walk you through them. If we talk about the SecOps, sorry, about FinOps, how we can save money, how we can reduce the cloud cost. The first thing that we would like to detect is if we have any stopped instance for more than six months, clearly we pay for it. And I will show you here an example for that. You can see here on the right side, a list of instances. On the left side, I built a rule to detect this. So you can see that I built a function, stopped instances longer than six months that represents the instance ID. Then I'm diving into the configuration. I would like to check if I have any reservation with at least one instance, with at least state.name.stop. If I have something like that, so clearly the instance is stopped. And you can actually detect it here in the JSON. And then, one second, I'm taking a property called state transmission, a transition reason. And you can see that it's a time. So I parse this time using regex, extract it. And then I built a rule to detect if this number is older than six months. And if the answer is yes, I'm tracking the instance ID. So let's click here. Let's evaluate the rule. And you would see the instance ID that is open for more than six months. The same also for EBS volumes, GPT EBS volumes. You pay for them. It's redundant. You should upgrade them to GP3. So I built here a rule to detect if the volume type is GP2 and the state is in US. And if I'm evaluating the rule, you would see the resource ID, the volume ID that is GP2. By the way, you can find it in Firefly, as I mentioned, for free. And we also give you the recommendation. I mean, the CLI command to upgrade GP2 to GP3, this is really useful. But let's say I would like to show you more examples. Unattached disks, of course, it's something that you pay money for it. So it's redundant if I have EBS volumes, that the attachment length is 0, then clearly I would like to understand which EBS volume is that. And probably I will remove it. More use cases for lambda function without concurrent execution limit, I can tell you a real story from Firefly. In a mistake, somebody deployed a lambda function and it has not configured the execution. Then we paid $4,000 a day, like this. So I would recommend to detect this as well. And if we dive into the secOps area, so we can find if we have any EBS volumes unencrypted with disk, you can see here if the disk volume dot encryption equal to false. We can run this rule and understand which resources, which volumes do not comply. The same for public EC2 instances. And here I'll give you one more comment for how we can elaborate this rule. I wanted to check which resources, which EC2 instances has public IP. So I will run this rule. You will see the instance I think. But what happens if right now I would like to elaborate the rule for understanding which EC2 instance has public IP, but the security group is open at least for 22, for SSH. And this is more complicated because it's dependencies between rules. So what we can do is we can build one rule that we will pass at least of all the security groups. So we will ask which security group is open for 22. Then we'll get a shorter list, and we'll forward the list to the second rule, to this one. And then we can elaborate our rule and not just detect if I have public IP. Also we can check if I have any security group that is part of the group of those that are open. And I'll give you an example how you can build something like that. So I built here a rule to detect unsupported lambda functions. And here you can see a list of lambda functions like a Python 2.7 or Node.js 0.10 point something. And I built here a rule that runs, that walks through the lambda and check if the runtime is unsupported. And if the answer is yes, I'm returning the function ARM. So exactly like this approach, you can do something more complicated, something more sophisticated, and build a combination of two different rules. Great. You have many other examples here for SecOps. For instance, to detect public accessible assets like EKS with a public API or Astribucket that might be public or Astribucket without a server-side encryption, very easy to mitigate just to configure the KMS key. Or this one, one of the first controls in CI's benchmark to detect users without MFA. And if we talk about reliability, obviously one of the most important things is to see tags, to understand that all of our instances or resources generally have an owner tag. So here I am checking that if we have at least one tag, that the key has owner. And then I can run the Evaluate button and see which instances. And I'll give you more examples for this. If the EC2 instance has public network interfaces, it's also more than one network interface. If the count of this is more than one, it's a bad practice and we would like to get notification. And I built here a broad deal, more example, for autoscaling group with a single availability zone or Astribucket without a versioning, et cetera. So before continuing, I'm stopping for a moment because I showed you right now Kubernetes and AWS. How you can leverage OpenPolicyAgent for governing your Kubernetes, your, you can create policies for Phenops, for SecOps, for availability, for everything that you want on top of your AWS and also for your SDLC. And I would walk you very briefly through that, but if you want to check that our Git that we defined some processes for our Git, we can utilize OpenPolicyAgent for this mission to detect that we avoid push to master. I mean that only by creating a pull request we'll be able to merge the code or test coverage. I mean that we can block CICD if the test coverage is less than 80%. For example, we can go ahead. What does the acronym SDLC stand for, please? Sure, SDLC is software development lifecycle. Okay, thank you. Sorry, that's complicated. Thank you for asking. We can also build a rule for the RBAC, role-based access control. I mean to define the groups and users on top of the Git. And if we talk about the Git configuration itself, we can define the code owner. And today that's mandatory. It's something that you should do to configure who can be the owner, who is the owner, the authorized code reviewer that can touch your, that can approve new pull requests. Or the repository visibility, if it's public or private. And if we have any, this, for example, is mandatory for SOP2 compliance. You must connect your pull request with JIRA. Using Open Policy Agent, you can do it. And I'd like to hear a question from the audience before I continue to the third part of the talk. I think I know what your answer is gonna be, but the question we have right now is, do you have any example for GCP with FinOps since you've been trying everything AWS? Sure, yeah. Sure, it's the same. GCP and AWS, of course, it's two different animals, two different type of sparrows, but you can find, for example, the unattached disk in your virtual machine, VM instance, or you can have a VM instance stopped for more than a month, or you can create a VM instance that is not utilized properly. Exactly what you can do. And if we talk about BigQuery, we can build a lot of policies regarding that to make sure that we utilize BigQuery correctly. Or if we talk about databases and let's talk about security, I would like to check if my database is encrypted. So it doesn't matter if it's Azure, Google or AWS, the whole idea behind is the same. So basically the rules will be different, but the concept is the same. Yeah, where can someone find the community written OPA rules? Because one thing I'm learning from your presentation is the possibility of what you can do with this is just so vast, it's so wildly vast. It's a little overwhelming for someone just hearing about it for the first time in a good way, like all the possibility it's exciting, the air is electric. But I think a great place to start would be rules that community has made. Where can we find those? Yeah, so there are some community, for instance, in Reddit. In Reddit, there is a huge community for OPA. You can see many people have questions. So I actually, sometimes you can find some Git repository, public Git repositories with the examples for OPA policy agent depends on your purpose. If you're talking about the cloud and IPaSkate has continuous governance, you can use Firefly to get least of all of those policies. Excellent. Great. Shall we continue to the next step? Sure. Okay, amazing. Cool folks. So right now, what I'm going to do is to actually block CICD using Open Policy Agents. I brought here telephone code that I built in the last session of CNCF and I'll tell you about this. And I will run the telephone plan command to see which resources are going to be changed. And then I built an OPA rule that detects the resources, the provisioned resources, the resources are going to be changed. And I'm checking if they have tag owner and tag environment, mandatory tag owner and tag environment. And if we are going to change a resource that does not comply with that, we will block the CICD. So before continuing and I'll explain all of this, I'm taking you back to the session that I have made in a CNCF a few weeks ago, with you, Whitney, by the way, that we talked about migration from cloud formation to telephone. And we used AAC to generate the telephone code. So here I built telephone code, fully operated telephone code, and I would walk it through the code itself. And we also generated a CICD, in that case, GitHub, GitHub Piping, GitHub Action, sorry. This one is the repository. This one is the repository, CNCF webinar and here under the actions, we will see here that we have a deployment that was generated by AAC. Here that's the telephone plan. All the resources that are going to be changed. But in the last session, we talked mostly about security. How I can take this and run security checkers like Bridgecore to stop the CICD, to block the CICD if we have any misconfiguration. So I'm taking the same idea, but instead of focusing specifically on check-off and security, right now I will show you how we can utilize the OPA for that. So let's begin very easily with terraform units. So give me one second and I will show you the telephone code. We have here a couple of services. If you will run terraform apply, it will create web application with some video. Then you have the provider, the latest one in terraform. You have the variables here and you have the outputs here. Here in the correct folder, I'm running terraform unit. In order to be able to run the terraform, we must run the terraform unit and then we will run the terraform plan. Next few seconds. Here terraform successfully initialize. Great. And now let's run the terraform plan. The terraform, let's start with the title. Next few seconds. You will see a couple of resources that are going to be added. 25 resources are going to be added. Zero to change, zero to destroy. So what I've done here is that I wanted to analyze only this and this. I mean, if I have something new, of course that I would like to block the CCD, or if I'm changing an existing resource that does not have the mandatory tags, I will block as well. So let's take the terraform plan and I will show you something that you should know. One second and I will zoom my screen. So OPA works with a lot of different tools. So you talked about cloud, you talked about Kubernetes, you talked about GitHub and now this is terraform. Is it, what's the limit? It's like everything? That's the first unified policies code. Yes, it's everything. Everything in policies code. You can use OPA really for everything. Yeah. Fascinating. Please, definitely. So I shared here before that I ran the terraform plan command and right now I can use the output attribute and that will save a binary file called tfplan. Okay, if I try to open it, you won't understand nothing because it's a binary data. But that's why I would like to introduce you to a command called terraform show. Terraform show actually read this binary data and extract it into JSON file that we can do something with that. So if I'm running the command down terraform show minus no color and the relevant tfplan, you'll see a huge terraform, sorry, a huge JSON file for the resources are going to be changed. Then I beautify here and I save the data into an output.json. I mean that right now in this file, I have the provisioning. What is going to be changed if I will apply my code? And I will edit here inside the regular playground. You can see that takes one second. You can see here that the modules here, the resources changed. If, for example, everything is aligned and I'm just trying the plan without changes, this list will be empty and then my rule will pass. But I have created here an OPA rule and I will elaborate on that because it's important for me to explain about it. But it reads, okay. So first I call the package set. Zoom in please. Zoom in please. Thank you. Thank you very much. Good. So first I created here a package CICD. Then I took the input and I changed it to tfplan just for being easier for me to understand. I built a generic function for as key and I'm utilizing this function here to detect if a list of tags contain the key. Then what I'm doing here is to run for each resource change. I mean only provisioned resources. I extract them and I set them a variable called resources. And now I'm creating a new variable called violations because for each resource from this list, I would like to check if the resource has the mandatory key, the owner or end. And if I don't have one, at least if I don't have both of them, so I have here a list of a bunch of resources. Then I'm extracting that address. Address means the location in the telephone code for those resources. And I'm creating a deny rule with explanation here. For instance, it's a medium and I added the policy description. It's a platform, you can do whatever you want with that. Let's run the rule and you would see the result. You can see that we have a deny. By the way, some of the resources here comply with the mandatory key. We assume it, yeah. Yeah, I know, cool. And I have a list of violator. As you can see, all of those resources, this is the resource type, dot resource name, that's a unique in Terraform. And then we can find the list of them that will block the CICD. Now I'm going back to the code. After explaining that I am taking the Terraform plan, JSON file, I'm running my rule on top of that. And right now, let me share the readme.md here. So I am adding the OPA rule to the OPA server as I showed you in the step one, step two of this talk. Then I'm running the following command. I would like to check and to get the result. I would like to get this result, the entire one. As you can see here. So I'm using the OPA server with my regular rule and getting the result. And I'm extracting the violator. So I'm creating a shell variable called violator that actually runs the, this one is the sending the HTTP request to the OPA server, okay. Exactly as I showed you before. And then I'm extracting the result.violator. I mean to extract this. So I will have in my shell list of violators in a variable called violator. Let's run this, let's equal, we have a list of results as then. I'm extracting the length, I would like to understand if I have any violator like that. So I also created a variable here in the shell script called length that checked the length of result cell. We can see 14 results as now I'm, I'll explain what I did here. If the length is more than zero, then it's not valid in creating the violators. Else let's run Terraform apply. So if I'm running this, I will walk you line by line. So it's a, the length is zero and then I'm equal. I think that it's not valid. The violator, else, Terraform apply, finish. We will see not valid and we block the CI CD. And you can go back to the previous top that I had here to get the step four of the CI CD using a CI explain how you can utilize it. And you can add one more step for OPA exactly as I showed here right now. And that's it for today. If my key takeaways is that you should use OPA will help you streamline your DevOps processes. You should, the most painful part of that is to understand which resources you have and then you can use some open source tool or you can use Firefly to fetch the resources for you because we do scan the entire footprint. And if you would like to build your own rules, you can also utilize AI to do it for you. So we didn't, did we see very much AI? And you showed AI very briefly at the beginning, yes? Or what AI did we see today? You see an open source tool that we have built. Yeah, you see, that is based on the JetChat GPT but we did the prompt engineering over there that you'll be able to get a more accurate result through that and using that, it generates the OPA rule for you so you save a lot of time by putting it back in English. So are there risks when you're, again, like I still see policy writing with, like it's important to keep your system safe but it's also like so powerful that you need to be careful with it too. So like what checks and balances are there when you're using AI to write your policy to make sure you're not accidentally making it incorrectly so that too much or too little gets through? Oh, that's a great question. Fast, don't put any sensitive information, personal information, PII, sensitive data, etc because you don't want your private keys to be exposed. So always take your terraform declaration of your prompt and make sure that you remove all of those stuff. And I'll give you an advice, it's a bit more sophisticated when talking about JetGPT. They have a declaration of something, definition, sorry, for something called temperature. It's a number between zero to one. Zero means no thinking, I mean no creativity and generating code use the temperature of zero. If you would like JetGPT to tell us a story, of course we need more creativity so the number would be closer to one. So yes, I encourage you to use zero temperature. That's fascinating. I didn't know about that, I love it. So then, what I'd like to hear, I'm interested in the AI part of this. And what's a real world example of someone using AI to improve their costs? Oh, I'll give you an example from one of our castlemen. They've been- Okay, great. We've been castlemen for five years but I really use it, it's really, really, really- I just walked right into that one. Yeah, amazing. So one of our castlemen use the AI AC, we call it the CHI, policies called AI to generate policies using AI and using that created the rule to detect GP tools for and there are so many things related to EC2 instances that are stopped, et cetera. And they generated AI, the castlemen saved almost one million dollars like this because we detected all of the EC tools and all of the GP2VS volumes and they removed all of them. Yeah, so that's why I encourage you to use the AI. That's great, it finally all clicked for me. I wasn't quite understanding the AI piece but the AI is what's going through your existing infrastructure which is probably vast and finding all of those instances that you can then write rules about. Is that correct? Yeah. And I'll just came together for me. That's super cool. I loved, if anyone has any questions, please do ask them, otherwise I'm just gonna keep talking so watch out. But one thing, so I do this show called Enlightening, you can see my lightboard behind me and people come on and they teach me about different tools. And I love also hosting this show because I did an episode on OPA so I kind of understand it from a theoretical level but my show doesn't have any hands-on coding. So then here I get to see what it's really like to use it and I've been enjoying this very much. So anyway, one thing I loved is like seeing how, I liked that you explained how rules get chained together and using the output of one as the input for the next one to do more complicated rules. That was really cool. I'm just telling you what I like now. I don't know that there's a question in here. Maybe there is, we'll see. I also really liked seeing the rules. I liked how human readable it was. Like, so some of that was you just doing a good job commenting and naming your functions in good ways but also just in general, Rego was maybe a little more usable than intuitive than what I expected it to be, than what its reputation is. So I thought that was cool. Yeah, definitely. And of course, if you can use the AI to elaborate the prompt and then for example, that's exactly what we do in the AIC. You can use chat GPT, but it will give you just the rule itself. So you need to train to give more context. For instance, RMLs, let's add comments and let's make it a human readable rule. And using that, you get an OPI rule that looks like you build it. That's cool. That's awesome. And it's so necessary because I think part of the benefit of policy as code two is like the people who are running the policy maybe didn't write the policy. So when something doesn't pass, it's very important for them to understand why it didn't pass. And it's a learning opportunity too for the people who make future EC2 instances to know or what to, like the Kubernetes examples you used at the beginning that like it has to have a compute limit mentioned and it has to have a readiness probe. So once they go through the experience of having it fail and understanding why it failed, then the next time they try to create a resource they'll know to put those checks in there. So I like that it's teaching the users a teachable moment. Yep. And there are many more examples. I just brought two, but there are bunch of examples specifically for Kubernetes for the deployment for the horizontal pod, the auto scaler, the HPA that you should configure. So one thing and not another about KEDA if those folks who use KEDA or a Prometheus configuration you can use a CRD of Prometheus. You can configure it properly using Open Policy Agent. Much, much more. We can talk about Open Policy Agent for hours. And then we can... For days, for years, I think. Like that's like a, that is like a really, it's a thing I learned before in the episode that OPA works with a lot of different tools. But now like today it's like really sinking in like how vast the landscape of like possible OPA. And then while you tell me when you chain together different OPA rules can you be chaining them together between different tools altogether? Yeah. Yeah, that's a super interesting question because the OPA rule is specific for the context. I mean, if I have a JSON model and the JSON doesn't look the same so we need to write two different rules. But is also a new technology for cloud specific right now called the cross plane. The debt, the share, you have heard about it? Yeah, I know a lot about cross plane, yeah. So for the audience, cross plane is a really interesting open source tool for infrastructures called cloud agnostic. Instead of building a few different resources like S3 bucket for AWS or block storage for Azure or GCS for Google, I can build the Kubernetes CRD for storage and decide that I'm going to deploy it on AWS. And then I'm building a generic resource, something that will be able to migrate between one cloud to another. And then on top of that, the OPA regular rule will be almost the same. Yeah, that's interesting. Cross plane just like OPA is just can be used in so many ways across so many different technologies that it is very, it's like exciting to see all the different things that people come up to do with it. But with cross plane, the way I like to explain cross plane generally is that basically you could take any kubra, any excuse me, any API in the whole, in the universe and then you can make it into, you can interact with that API via Kubernetes with cross plane. So it brings that API into Kubernetes. And then you can use that control loop, you can integrate it with the rest of your system. It's super cool. That's great. I'm looking at this specifically from the cloud perspective because I'm a cloud client. So that's why I'm a cloud client, yeah. And that's, I think the most popular use case for it right now too is to use it to provision and manage cloud infrastructure. I have a question here from Akash. Let's see if we can get it on the screen. Oops. Can I use Azure open AI? Azure open AI, of course you can do. I don't know if you mean for using AAC using Azure AI, we added the support for that. And by the way, in Firefly, we also utilize open AI in our private instance in Vine. So I really recommend using Azure open AI and it's great. Awesome. Well, I think we're wrapping up today. Is there anything else that you wanna say before we say goodbye? And that's something specifically that I already sentenced for in each target and finish with is that while coding your telephone code, while coding your infrastructure, always keep your secrets safe. I mean, don't push secrets to the GIF. And it's not related specifically to this stuff, but I would think it's kind of safe. We should just end every single episode that way always. It's just good advice. Yeah, excellent. Well, this has been an absolute pleasure. Thank you for showing us about open policy agent and specifically how we can use AI to really supercharge how you can enforce policy across your entire cloud estate. That was amazing. Okay, I'm gonna read the ending strip now if you feel ready. Okay, I have a script here. Okay, thank you. I would have said thank you anyway, by the way, regardless of whether it was on my script. But anyway, thank you everyone for joining today's episode of Cloud Native Live. Thank you so much, Steffi Janus, teaching us about supercharging your infrastructure management with open policy agents. The chats, y'all were amazing, like always. I loved the questions and the interaction from you. And I love seeing where all y'all are from. I'm from Texas, if you can't tell me putting all the y'alls in there. Here at Cloud Native Live, we bring you the latest cloud native code on Tuesdays and Wednesdays. So thanks for joining us today and we have another episode tomorrow at the same bat time and same bat channel. And thank you everyone who watches the recording and we'll see you again soon. Goodbye friends.