0:05 Hello, and welcome back to Rawkode Academy. Today, we're continuing the complete guide to Kubescape. Kubescape is a tool that allows you to scan your Kubernetes manifest and clusters to detect misconfiguration and security violations using all the popular is that the right word? Popular security posture frameworks like MITRE, SIS, NSA, ARMOR BEST, etcetera. Today, we're gonna take a look at building our own framework. You can do this on easy mode with ARMOR cloud, and we'll walk through exactly that. However, I wanna dive in to what it takes to build your own framework on your own machine with your own JSON

0:51 and no cloud. But let's take a look. Alright. Let's take a look at easy mode first. So this is ARMOR cloud, which you'll have seen from the first two videos in this course. We're gonna click on my face and go to settings. From here, you'll see that I have three inactive clusters. We're just gonna ignore that for today. On the left, we have posture, which has frameworks and controls. So let's click on frameworks. Here, you'll see that we have all controls, ARMOR best, DevOps best, MITRE, NSA and SIS. We are gonna use the new framework button

1:42 to create our new framework. See, I told you this was easy. So let's name this Rawkode cloud. I'm calling it Rawkode cloud because this is the framework we are creating using the cloud. And I don't want it to clash with what we do on the command line shortly. You can give it any description you want. Funny. Right? Next, you can select the controls that you want to check for. So let's search for host. We want to ensure that there is no host page access, container host ports, or host path mounts. We click apply, And if we scroll down,

2:33 we have Rawkode Cloud, any description you want with three controls. Now we can edit this whenever we want and bring in new controls whenever we want. Now why do I think this is important? Well, I've worked with a lot of I've worked with a lot of teams that want to improve their security posture, but they can find the default policies overwhelming. It can be quite intimidating when you see that you have so many violations across so many Kubernetes manifests across so many Kubernetes clusters. And what they want is just the easy mode. Well, how do I just check for

3:16 like the really bad stuff? Because you know, there may only be a few rules that you wanna start out with, but when you build that habit, you show people progress. This kind of change becomes a lot easier, especially when you're working with developers who just may not be accustomed to this terminology and smishy smashy language. Now now that we've created our new framework on ARML cloud, we can pull that down to our local CLI. Alright. Let's get started. The first thing you need to do to make your life a little bit easier on the CLI is to export

3:56 KS account and set this to your account ID. If you're not sure where to find that, go to the cloud, click your name, and click copy. Like so. Now, you can list your frameworks. And you'll see at the bottom, we have Rawkode Cloud. If you want to, you can cache these offline with download artifacts. And you'll see it's downloaded our Rawkode Cloud and to the current directory. So if we take a look at the current directory, we'll see all of the frameworks, plus I have a deployment YAML, some queue, and my own JSON. We'll get to that in just a minute.

4:51 Let's run Kubescape scan Rawkode cloud dot. I'm saying that I want to scan that deployment dot YAML in this current directory against my Rawkode cloud framework. Now we can see the violations. Now this is a very standard NGINX deployment dot YAML. We don't have resource memory limit requests, etcetera. I'm not doing the good security stuff to block privilege escalation and I'm pulling it from a random Docker. Well, I'm pulling it from the Docker Hub registry. I don't have really any labels blah blah blah blah blah. Thank you, Kubescape. So that's kinda cool. And I would encourage you and I can't

5:42 stress this enough. I encourage you to use ARMOR cloud, build your frameworks from there, expand on them, bake them into your CI process. We've already done a video on CICD with Kubescape. So go watch that next if you haven't already. But but what if you want to do it the hard way? What if you want to build your own framework locally using your own tooling without interacting with Rawkode? Unfortunately, this is all very undocumented and it took a lot of reverse engineering and by reverse engineering, I mean, just scrolling through GitHub code to work out how this all works.

6:32 Let's build our own framework on the command line. Now why am I gonna show you how to do this when building a framework is so easy on ARMOR cloud? Well, because I also wanted to explore and experiment with building my own controls. ARMOR cloud is great for taking existing controls, packaging them up, and iterating or expanding on them to secure your security posture. But if you want to write your own controls, it really means speaking to someone at ARMOR or filing a pull request. So what if we just wanna iterate and hack on locally? So let's take a look at the ARMOR

7:18 best JSON that we got during the Kubescape download artifacts. And what we can see is that a framework is a JSON object. Now you probably already knew that because you've seen the downloads when I ran cubescape download. Yeah, nah, nah, But it has an array object with controls. Each of these controls has some attributes which we can ignore for now and some rules. Then these rules match against resources within our cluster and then some other mumbo jumbo. Let's take a look at all controls. Here we have forbidden container registries. It too has some rules where it wants

8:13 to block certain image registries. Now you can see here that the language for this rule is Regal. If you're not familiar with Regal, it's the policy language from the Open Policy Agent project. Now if you're thinking the existence of this flag means, hey, cool. I thought you thought that Ragel, maybe I can write my policy in another language. Unfortunately, this is the code that runs your policy. Ragel and Ragel two are the only supported languages at the moment. But maybe this will change in the future. I think it would be kinda interesting to see STARLARG or common expression language as an

8:52 option for right of policies. Again, we match on the resources that we want to apply this to. And the last thing that we haven't really covered is that we have to rule itself. Now this is just because the shift is JSON. We have a complex string stored as a string value. It has new lines as tab characters, it has comments, it's got code. This is not a pleasant experience to modify your own custom framework and controls locally, but again, again, it's not made to work like that yet. This is just me hacking around on stuff

9:27 that I shouldn't be hacking around on. And I thought, well, what if we wrote it in queue? We could export the queue to JSON and use the custom framework that way. And that's the path that I went down. Let's pop up in the queue. I'm a big fan of queue. It allows us to do cool things that we can't do with JSON, YAML, and other formats that we've been stuck with for many years now. So I encourage you all to go and find Q tutorials online and improve your data configuration lives. First thing I do is I'm setting a

10:09 private variable. Now I'm not going to go into queue in a lot of detail, but understand that a private variable is anything with an underscore. When I run queue export, that will be wiped off the face of the planet. We're using it to avoid a little bit of duplication further down in the queue. Now my usage of it here is relatively contrived, but I wanted to show you one of the small little perks of using queue for this kind of tool chain. We name we name our framework, and then we start to add controls. I've called this control, you know, Rawkode Academy

10:49 images. Description? Well, Rawkode Academy is risky. We don't trust them. Remediation path? Don't use their images. Once you have a control, a control has rules. Here we have our first rule called no RKA images, and then we have a rule. So already with q we have access to multiline strings. That means that we actually get a relatively pleasant experience for editing the Regal code. It's worth pointing out that the q team are working on embed like syntax similar to what you get with Go embed. Meaning, in the future, we'll actually be able to do policy dot rego and load it

11:37 from its own file. That's really cool because it means that we'll get rego based syntaxing because it's in a rego file. So cool thing to look forward to in the future. Now if you're gonna go down the path of writing your own controls this way, there's a caveat. Remember, it's not built to do this quite yet. So you have to name your package ARMOR built ins. This is just a caveat right now. I'll include an issue in the description if you wanna track and see when that changes. Other than that, you're right in straight up

12:11 Regal. That means you can actually use the Regal playground to test your policies or even open Regal Toolchain locally. It's up to you. Here, we define untrusted image, which pulls out the pod from our list of resources. We pull out the kind and make an assertion that this is only gonna apply where the kind equals a pod. Next, we iterate over all the containers. Now iterators and Rego are a little bit weird and you have to get used to them. Just know that when we reference something with a variable like I here, we're gonna loop over that list.

12:55 All subsequent assertions will be against each item and that list. Next, we pull out the path to help us provide good debug and error messages for failing policies. We grab the image and we call the RKA repo check function against that image. This function is extremely trivial. We call the start of function to check if our image starts with ghcr.i0/RawkodeAcademy. If we get a failure, we provide a message that tells the user what went wrong, and that's it. We set the rule language to Rigo, We tell it which resources to match against, and we provide some description and remediation instructions

13:47 for this particular rule. We have to provide a list of control IDs at the bottom. Hence, I'm using my private variable to loop that in. That's it. So how do we run this locally? Well, the first thing you're gonna want to do is the q export of Rawkode.q. This now gives us a JSON object that we can store locally and I'm going to store this in Rawkode dot JSON. We're now in a position where we can see Kubescape scan use from, which means that we want to use a local policy or framework, and then specify in Rawkode dot JSON.

14:31 I'm then going to run that against my deployment YAML, and I'm just telling us to spell out the results as JSON and a control format rather than a resource format. You now have our report dot JSON because of our flags, and we can see our high severity, no Rawkode Academy images has failed on one resource for the Rawkode framework. Neat. So as we can see, if we want to remove this violation, we can update our deployment dot YAML, and we're gonna use a slightly more trusted NGINX image. Now we don't need all of these flags,

15:14 we just need use from and a scan target like so. And now we have no failed resource. So this could be a really interesting way to build up your own framework with your own controls. You can write your own Rego and ship them via git. You can hook this into your CI process and improve your security posture step by step, control by control. Now I do strongly encourage you just to use ARMOR cloud, but if you need to go down the custom controls path and custom Regal, that's just how to do it. So if you found this useful or you need some

15:54 help, drop straight into the comment section. Until next time, have a great day. I'll see you soon.