 Hello everyone, welcome to this on-demand CNCF webinar on whether your Kubernetes is positive or negative. I'm Shoryu Rosem and I'm going to talk about QtScape, which is the first open source tool for testing whether your Kubernetes is deployed securely according to the best practices and the complex frameworks multiple of them in just one click. Please, you know, it is an open source product. We would really love to get your engagement stars and GitHub, join us on Discord to get all of the updates and get engaged or visit us on our website. Armo is the company behind QtScape. Just a note about myself, who am I? So I'm Shoryu. I'm the CEO and co-founder of Armo. I'm a software developer turned into a neural and today my life is basically waking up in the morning, 5 a.m. for surfing, 18 a.m. with Kubernetes products, 9 a.m. for QtScape and then repeat. I do it basically every day and I kind of like it. So, you know, I really, really like it and I really like sharing it with you guys. What are we going to talk about today? We're going to first talk about why do I care and what can Kubernetes do for me? Then we're going to one hour first scan. It's going to take less than three minutes. I'm going to show you how to analyze results and get more information and more benefits out of QtScape and the Sats version of it. We're going to talk about adding QtScape to your CICD end clusters to get continuous protection and then once we're done and configuration is all set, now what? How do we take care of the next step of our security? We're going to touch on that just a little bit at the end. So why do I care? Well, configuration is a big problem. By 2025, it said that over 99% of the cloud futures will actually be coming from the root cause of customer misconfigurations and already today, 59% of the server respondent in companies using Kubernetes say that detecting misconfiguration is one of the biggest problems that they had in the last 12 months, but it is a big problem. And how do you address it? One of the things that we see from our customers and from our users is you really sometimes don't know where to start. How do I know that I'm doing the right tests? How do I know that my cluster is actually okay? How do I sleep at night? And first of all, the first answer is you don't. You never know that you're done with misconfigurations, but you have best practices, frameworks and guidance that will help you understand where you are and help guide you through what tests you need to check. We specifically in our more currently using the middle attack framework and the Kubernetes southern guidance that was issued by the NSA. CIS is already coming, but it's also a great framework to use. And we also actually created our own framework, the armor-based practices that you can use. What Kubernetes does for you is takes your cluster or your configuration and compare it against the test that we've created that matched those frameworks. It can be done in the CISD or on a running cluster. And if you choose to do it in the CISD, we are integrated with, you know, all of the different CISD tools like Jenkins, GitHub, Azure pipeline is not here, but we're integrated with it. And it's pretty easy because it's an open source tool. It's also by configuration. It's really, really easy to edit to your pipeline. Just, you know, if you like Cubescape and, you know, you could use many tools. I like Cubescape, but I'm very, very biased. But also many of the users in the community like Cubescape. We have over 4.5 stars in GitHub, and we have a lot of followers and we get great, great, great feedback from the community on the product. And we actually engage with the community and we ask you to let us know everything you love, but also everything you don't love about the product and about the project. And we will continuously make it better and better. Your feedback is super important for us. So we talked a lot. Let's actually do some actual work now and get our first scan going. The best way to go for your first scan is our GitHub page. I recommend going there. You have the installation scripts there. Everything is ready to be available. The nice thing about Cubescape is you can really get that in three minutes to just get started. It requires knowing how to installation. It only requires with only privileges from your CUBE API. So it is very, very easy to get started. So with that said, let's go to our GitHub page. I'm just going to search for GitHub. GitHub. Cubescape. Here we go. And I can see that I can get started with basically running this command, the curl command. We got some feedback and I completely get it that people are not very fond of finding an install script into their bash. I agree with you. You can take a look into the essential file. It's all open source and all available for you. I would recommend downloading Cubescape and installing it yourself. But I've run this so many times and for this demo, I will definitely use this one liner. If you ask me, you can use it, but of course, always check what you're running in your clusters or on your machines. So I have a cluster already running here and I'm going to install Cubescape on it. It's not a cluster, it's a machine. And that's it. I have Cubescape installed. And now I can actually use it to scan my cluster or my YAMLs. In this machine, I have access to a running cluster in GCP, which is one of the extra shop. But I'm actually not going to start by scanning the cluster. I'm actually going to start by scanning the manifest that is actually driving the cluster. I'm going to do it to mimic the CICD test that we can do on the YAMLs. So let's do that. Let's run Cubescape. Scan. I'm going to use the NSA framework in the same and then I'm going to put micro services demo, Kubernetes manifests, no, I'm sorry, the file is in Cubescape demo, I'm sorry for that. Cubescape demo, micro services demo, release, Kubernetes manifest, YAML, I'm going to basically scan that right now. Let's give it a minute. Okay. And we are done. And we have our first scan. I hope it was under three minutes. I think it was. And let's see what we got here. I remind you that we tested a manifest file, a YAML file. So we don't have the entire cluster context. We don't have the control blind. So many of the tests that you see here are actually not relevant for that specific manifest file. Let's see what is relevant. So let's start with allow poolage escalation, for example, we can see that we have 12 resources that actually allow poolage escalation in their containers, a problem that I should probably fix. Another one that I'm very fond of is the immutable container file system, which we have again, the same, probably the same 12 micro services, which actually allow access and actually allow the container to change the file system of the underlying host, which is very, very much not recommended. So we can see that. And we can actually, if you go up, we can see which resources have failed which tests and let me scroll up a bit. So if you go back to our first test of allowing poolage escalation, we can see that the email service check out basically all of the deployments in this time space are problematic. And we can see the radiation that basically tells you to add a security context and set the flag to false. And we can see more of that in our documentation. So this is how we scan and we can do it in the CLCD, we can scan any YAML file and test it again, the best practices of the NSA or the midway. But now let's do the same on an actual running cluster. It can be your development cluster or it can be your death cluster. All it requires is read privileges. And then we will have many of the tests that were not relevant in this specific file, you know, now they will be relevant. So let's do the same. My cube CTL is already pointed at the cluster. So all I need to do is run Cubescape, scan framework, and then the name of the framework, which is the NSA. OK, so you can see we have the NSA framework and I'm going to run it out. So now it is running, uses Cubes CTL to access to the API, the cluster and read all the configurations and test it. OK, so we see that many of the things that were not relevant before are now suddenly relevant. So, for example, things like control plane hardening is now something that is actually testing the three components, things like exposed dashboard, whether we have a dashboard installed is something that is being tested and also executing to containers now has more results in it because actually in the cluster, we have roles that can execute to containers. In the YAML, we didn't have that, but when you deploy GCP by default, it creates some administrative role-based that actually can execute to containers. And you should probably check that. And again, you can see everything that failed in the actual results in your screen. The next thing that I want to share with you is, OK, you get the results in your screen. It's really nice. It's a report, but how do I automate it? How do I make it part of my CICD? And that's where it is very convenient to use an output format like JSON or JUnit for, for example, for Jenkins. So this is how we thought about that. And you can run the same test again and you can put format JSON, for example, and output to a file that will be actually running in your CICD. Let's call it test.json. And basically, you can now get the results as a JSON file, which can be really, really easily integrated into your pipeline. We can actually also point the standard output to JSON, so it will be actually completely automated. So if I'm going to do a VI test, naturally, I'm going to see the JSON results file and very, very straightforward. Let's get out of that. GCP is actually working a little bit slower today. OK, so now that you've tested cluster and you've tested the YAMLs and we know what we can do, let's actually see a better way or an advanced way to actually analyze the results and see when it continues to run. And this will be done by actually registering to the SAS part of QSCAPE. If you run the results, if you run the tests, just one more time, give it a minute. OK, at the end of the result, you actually have a link to our portal where you can submit the results to the portal and start to get ongoing scans and ongoing results. And you can have advanced features of what you can do with the system. You don't have to, of course, do it like that. You can just go to portal.arm.cloud and sign up there. I'm already registered, so when I will go into this portal right now, I will already get the different clusters that I have scanned. And I can see the threads in my clusters. I like to look at it in a list format. And this is the cluster that we just conducted the tests on since SCF webinar cluster. But you can see many different clusters here. And let's see what type of results I can see if I go into those clusters. So let's start with looking at this cluster that we have here. The way I like to look at things is, first of all, of course, the total risk score and the better my score, the better my cluster portion is. And you can see that, of course, right now everything is the same because all of the tests that I've done are on the same, a cluster with the same configurations. The way I like to do things is first to sort controls by severity and to, first of all, check the most critical severity and controls. I can see here that I have privileged containers that I've excluded. This I've done that before, which basically says that I actually saw privileged containers that I approved to run as privileged. I have application credentials and configuration files. I have five workloads that have that. If I'm going to look at that, I can see that one of them is in the default, in the default main space, but other ones are actually in the control play main spaces. And you need to see to see if we can fix that. We can see that we have different workloads that have allowed host pass that can actually change the host pass. Let's look at them. OK, these are in the cube system. Actually, and we have this slide will be that says this is actually OK. There's not much you can do about it. It does it for you. So I will exclude it in order not to get reallerted in the future. The exclusion mechanism is very, very powerful. And we are continuously adding more recommendations to do auto exclusion because one of the main things you want and we want to do is to reduce the number of alerts that you're getting and only get you into a place where the alerts that you get are really meaningful. If you look at some of the things that we have, let's let's look at the law of public discretion, for example, we can see we have 12 workloads that have been identified that allow public escalations. We can see that because of the the recommendation that we got, we excluded the system, but we have 12 microservices in the different namespace, basically all of them that actually allow public discretion. OK, what do I do about that? I go to the documentation and I will see what this test is all about. So we can see that it is about attackers getting access to the container, uplifting the privileges. And we have the remediation here and actually an example of what I should do. So what we see here is that those microservices in the different namespace are missing a security context with the allow public escalation flag set to false. By default, it is true. So because we didn't edit and we have a misconfiguration, this is something we need to take care of. Another another test that I really like to look at is the host network access. Let's see host network access. We can see that we have six resources that they failed this. And if I look at them, in this case, it's a cube system. And it tells me, look, you can make an exception. So I'm going to make an exception. But what is this? What does that mean, the host network access? I can again go to the documentation and see exactly what it means. I hope that makes sense for you. Now what I want to show you is how by continuously checking your cluster, we can actually create drift control. So let's take another cluster, which is actually running for a long time now. Let's take this one, for example. OK, you can see that I have many, many tests in this specific cluster. But now I want to show you a different one. This one, I have so many clusters running here. So bear with me. OK, let's take this example. And let's see if we have drift we can identify here. OK, so let's take at the midway, for example, we can see always what failed in the latest test versus what failed in the previous test. We basically use the previous test as a benchmark, as a baseline for the drift control. And you can set it any way you like. And what you will see is that if you have a drift, we will alert you on it. And in this case, we actually made things better than the last results. We have zero micro-services, that leads Kubernetes secrets in the new deployment. So someone actually fixed this problem. And we have zero service accounts that have access to the container, workloads that have access to the container service account. So this is actually a good drift. Basically, what we want to do is we want to reduce it as much as possible. And then we want to make sure that we don't have any new micro-services with that vulnerability. Let's do an example. And let's try to add, okay, I'm going to do it later. I'm going to show you in this facility how you do that. Another thing that it is important to note that for your organization, you might want to have your own framework. You might want to create your own control and your own framework. And we can do that with Cubescape. You do that by going into the settings tab. Here you can see all of your clusters and you can see all of the frameworks and the controls and the integrations that we have. You can use the stack integration in order to actually get the drift results into your Slack. So you can actually set our Cubescape to continuously scale your cluster, let's say once a day. And if it sees something new, a new vulnerability or as you can see at the degradation in the posture score of your cluster, it will send it to you via Slack. Now let's look at the frameworks. We can see that we have four frameworks in and we have the Shauli framework that I've created. I will delete it, okay? And I'm going to show you how I create a new framework. There are different ways to go about it, but I will just create a new framework here. And I'm going to put the framework name, which is CNCF Webinar. I'm going to, I can put a description. Capital letters are not allowed, of course. Demo, framework, all the CNCF Webinar description. And then I can choose exactly which controls I want to have in this framework. So as an example, I can check whether the cluster is internal networking enabled. I really like, as I said, the host network access. I want to make sure, I'm not going to put control pane hardening. Actually, I'm going to also not do cluster internal networking because what I'm going to do, let's actually create a framework that I'm going to use in my ICD, which is actually, it's going to be smaller, it's not going to have many, many controls in it, but it's going to be a sanity check for my developers. Every time they commit to GitHub, for example, in New Yemen, it will be tested against this framework. And then we will know, and they will be alerted if they did something that is actually bad practice in our organization. So let's do that. I think that's actually a smarter way to go about it. So of course, I want to make sure that they don't put any application credentials in the configuration files and config maps. What else do I want to check? I want to make sure that there is no host network access, that there is no container host port access. Control pane hardening is not relevant for the CICD. Also, not the malicious admission controller. I want to make sure that they put resource policies, basically CPU and memory limits, and I can actually go and set exactly which ones I want to have that I'm going to show to you in a minute. I don't want them to allow host pass. I want to make sure they're using mutable container file systems. I don't want them to use privilege containers. Just for the sake of it, let's also do, I don't want to allow religious creation. That's it. That's going to be my framework. And this is a framework that I can now apply in the CICD and I click on apply, and that's it. I have this framework. If I go into all of the controls, you can get all of the controls with a very specific description of what each control does. And you can actually also do it from here. So you can actually click on add and add a control to a framework in case it's not already there. Let's take an example from here. So let's say a Linux hardening. So no, let's do dangerous capabilities. Dangerous capabilities is basically a control that checks that dangerous capabilities are not enabled in the containers or in the ML files. I'm going to click add, add it to the CNC formula. And now I added it to my framework. This is the control that can be configured. Armor by default, make sure that you don't put privileges like all CIS admin, net admin, CIS pit race into enabled in your containers. But you can actually change that. You can add your own, or you can actually delete some of those if you want to allow them in your session. So that's what you do with the casting framework. And now you can also use it. So if I go back into Cubescape, and I'm going to run Cubescape scan framework we call it the NCF webinar. Okay, so you can see the test that we have chosen and we can see what failed and the percentage of the score you have against this framework. And I remind you, this is the phone that I created for myself to integrate to my CSCD and actually have my developers understand exactly what they're doing wrong in terms and they are having a misconfiguration in their ML files. So what I'm going to talk about next is basically what we've done so far, right? And we've analyzed our results. We've seen how we can control drift, how we can set exceptions, how we can understand risk of the time. We're actually adding more capabilities like how to control and when a bit is coming to this version. So I'm actually encouraging you to go to a GitHub and get informed or go to our Discord and get informed about all the good things that we're adding there. But now let's talk about how to practically use it. So all we did right now until today is we just basically did scans on an, I would say, as you go manner. I kind of like whenever I wanted to, I ran QtScape and I got the results. But I want to do it in a more automated way. I want to put it either way into my CSCD. So that's one way to go about it. I can integrate it to my commits or I can integrate it to my pipeline. Those are very good practices to do. And I can also run QtScape in my cluster. So I can actually periodically scan my cluster to get the results. And all of that is very well documented on our user hub and on GitHub. And I encourage you to go and see there, but I'm just going to give two examples right now. So let's start with actually getting QtScape to run every day in my cluster. I want to wake up in the morning, get a report on where is my configuration posture today versus yesterday. In order to do that, where you really need to go is to our GitHub page. We have, it is all documented, but if you go to examples and hand chart, you have basically a hand chart which defines exactly, you know, you just deploy this hand chart and you get another control in your cluster, which continuously runs based on the scheduling that you have decided to do. Let's go to do, let's do it right now. So I'm going to clear. I already downloaded the hand chart. Let's look at it. Sorry, it's under QtScape. And the VI examples and chart values. And what you can see is that this hand chart is configured to run basically every day at midnight. If you want it to see, you can actually do it and get the results into a file or whatever you want to do, or you can connect it to our backend as I showed you and to see it in an ongoing manner. If you want to do that, you need to go here and put your customer ID or account ID that you get there from our UI. And let me show you where you can get it. So if I go here and I want to add a cluster for example, or you want to do anything like that, you can see that I have the account here and all I need to do is edit that token to my QtScape. And again, everything is very, very well documented and I encourage you to go look at that. So we have everything set up. I have the cluster name. I have the customer name Guru and then just need to install this hand chart. Okay. I'm going to do hand install example, okay, QtScape. I'm still QtScape. What is the name? Okay, that's it. From now on, this cluster will be scanned by QtScape. Based on the data safe framework, in this case, based on what I wrote there and will actually do and I will be able to see every day the results and what changed in my cluster. If I'm looking at how it looks like, so this is for example, a cluster that I already have a running in an ongoing manner. And you can see that I have a trend of everything that is going on here and I can actually see and understand the state of my cluster. And you know, just for the sake of it, I also once did this, you know, let me see, where did I do it? Mm-hmm. I think it was here. Okay, I also did like a scan that is done every minute. Ah, here we go, you see this is here. So if we go here and I look at the scans, I can see that this NSA, you know, not NSA. Yeah, so didn't know. Ah, okay, it's only two. So it's not that one. Nevermind, I once did a test where actually when I scan every minute and it's kind of cool to see that but I can't find that cluster right now. That's what happens when you try to improvise in a webinar or a live recording of a webinar. So we covered that. We can now have a constant actually scanning of our cluster but now let's actually integrate it to the CCD. We remember we wanted to make sure that our developers are not making mistakes and we want to help them. So, oh, what I did to do that. And now, as I said, I want to integrate it into my GitHub actions. I created this GitHub repository just for the sake of this demo. And if I want to get and use that and I want to know how to integrate to the CCD into GitHub, you can go to our documentation page. Let's go to our documentation hub. The GitHub integration sections, GitHub actions and you see that all you need to do is add another file under GitHub workflows with this data in it. You have the example here. I already did that. So we have under GitHub workflows. I have the ScanYAML which is, which has basically a copy paste of the example. And what I have is this very simple repository, just one YAML at the front end YAML. And every time I update it, the workflow runs and QtScape runs against it. So if I'm just going to do it now, let's make a change to it just to have it run. Let's add here in the comment, low world. Okay, and submit it, changes. That should trigger the workflow. And we can see that the update workflow is running. If I go into it, I see that there is an NSScan running. If I go into that, the job is still running. Give it a minute. Okay, it's done. Okay, we can see that everything is done. And we can see the result of the ScanYAML file. And we can see exactly what's wrong. And as I said, we can actually, I did hear the NSSframework. What I could have put here is the smaller framework is just the thing I want my developers to actually make sure that they're doing right. And I can actually integrate that now to see the GitHub action into the pipeline itself. I can fail the pipeline. If the best practice is not holding, I can do all kinds of things with it. So that is super, super powerful. Let's just look as an example. Example, let's look at the emutable content file system is passed. Let's say it's something that failed. It's interesting. Allow people to scale. Okay, the first one is actually failing. And we can see, and we know, and we saw it earlier, what we should do in order to fix that. We saw that in the documentation. So if you go back to my code and to the front end, of course I prepared it. I'm gonna edit it. And I'm a developer. I know that I need to make this change. You go here to the security context and instead of with only two, I'm gonna put false. And I'm gonna click submit or commit. And the workflow will run again. Let's let it run, okay? It's cute, probably because of an overload. Here we go, it started, and it's done. And there's no magic here, basically. And now the, you know, the escalation is still failed. So what we're gonna show now, as I said, we're gonna see integration to GitHub Actions to actually have our developers check their code every time they make a commit. In order to do that, I'm gonna go to the GitHub Actions integration instructions in our user app documentation page under the integration sections. And we can see that integrating with GitHub Actions is super easy. All you need to do is add a folder, GitHub workflows, create a file there and have this content, you know, in the file. I already went ahead and did that. So we have the GitHub workflows here and I have a file called scan, which has the exact same content, just copied from the instructions. I also added the account database, so I can see what my developers are doing. And I'm running the NSA framework. I could run the custom framework that I created, the smaller one, it is super powerful because once you do that in your GitHub Actions, you can actually fail the commit based on the GitHub Actions. You can actually put the output, not only in text and actually send it to the slack of the developers who did the commit and all kinds of things like that. But for now, for this example, I'm just gonna show it, I'm just like that. So let's make a change to our frontend diamond. This is just one diamond in this GitHub repository. I'm gonna edit it. And just for the sake of it, I'm just gonna remove the comment here just to create the commit. So I created the commit and now what happens in the action is that the GitHub Action is starting to take effect. It sees that the frontend diamond was updated and it will start running. We can see that it does the NSA security check and it's gonna take a few more seconds. And I can now look at it. I see that it ran. I can put it into my CI CD. And I see, for example, this failed tests that they failed. And one in particular that I'm gonna show you as an example is immutable file system. So immutable container file system, this is the best practice to make sure that the flag is with only and this was not done by this developer. So now he says that it failed. As I said, it can be actually sent to you in Slack to show you the stack integration before. And now I'm gonna fix it. How do I fix it? I'm gonna go to the documentation or I can see here that I need to add this flag. And now I'm gonna go back to Miami and make the change. Of course, I already did it before. So just commented out here. And now with only file system is true. And I'm gonna commit changes. And again, the flow has been run. Did not start to run yet. Here we go, it started to run. And again, it's gonna take a few seconds to run. Great. And if we go to the results now, we can see that the immutable container file system is now passed because we have fixed the misconfiguration. And as I said, this is super, super powerful because now you can actually put it and you can actually make sure that the build is depending on it. You can decide that it's not depending on it. It's very, very flexible for you as a tool. And you can actually limit it to only the test that you wanna enforce in your CECID or that you wanna know that your developers are doing. So that is basically, you know, if I go back here. So we talked about ending a courgeo that we test every day. We talked about how you can edit two different CECID pipeline tools and we showed it on GitHub. And that's why Cubescape is very, very powerful and covers you in many, many elements of your CECID configuration to production configuration checks. So we're done. We're feeling good with our configuration, but now what? So unfortunately, even if you continuously fight misconfigurations, you will only, we will always have some more misconfigurations in your environment. And the next things that you need to care about is really the next things in our survey. Security incidents in one time, vulnerability, and mitigations, software vulnerabilities, audit logs, and those type of tools. And that's where, and that's the only thing I'm gonna say about Armo, but that's where the bigger Armo Enterprise version of Cubescape come into place. That actually takes you not only for configurations, but also for the deployment and production in the application protection. That's our wider platform. We cover, you know, via Cubescape, we cover your checks early in the CECID. And then you add more functionality like continuous portion control and run times your task to cover those elements that are not covered by Cubescape and other scaling tools. This is a core runtime security that we believe you need to add to your cluster and we made it very easy for you to do that. The way we work is via a zero trust model. I'm not gonna go deep into that. You know, you're welcome to connect with us. And basically we can actually apply one YAML to your namespace or cluster and immediately we protect each one of your microservices, assure only your microservices. Only as long as they're not compromised can actually run communicated access data in your environment without the hassle of so many different network and security policies, just one overarching, very deterministic policy. We've patented it and I'd be happy to speak with anyone about it, but that's not the topic of this specific webinar. So thank you so much. I hope you enjoy this webinar. I try to be as practical as I can. I really hope you do go to our GitHub and follow us and I do hope that you do give us a star in general at this fold and join this community and help us make Cubescape a very, very good tool for everybody to use. So thank you so much and have a great day.