0:00 Introduction

0:02 Hello, and welcome back to the complete guide to Kubescape. In this second video, we'll be taking a look at how to use Kubescape from your own machine via the Kubescape CLI. We'll then be progressing to using Kubescape in CI environments like GitHub Actions, allowing us to scan for misconfigurations right from the pull request. Before we get started, thank you again to Armo for sponsoring this series on the complete guide to Kubescape. Let's have some fun. Alright. Let's take a high level look at the Kubescape CLI. First, we can run kubescapescandot. Now before I run this, I'll just show

0:33 Kubescape CLI Basics: Scanning Directories

0:44 you that in this directory, we have the Google microservice demo and the Weaveworks Sockshop demo. So there's a lot of manifests and not only that, there's a mixed variety of types of manifests. In some of these directories, we have a helm chart, and some we have customized, and some we have straight up Kubernetes YAML. So let's run Kubescape scan dot. This will scan recursively through all of these manifests and types of manifests to give us a report on this configuration. Nice. So from here, we can see that we have 48 failed controls out of 70,

1:26 Analyzing Initial Scan Results

1:35 but none are critical. So silver lining. As far as the high severity goes, we can see that we are delivering application credentials and configuration files. We are not applying security context to pods and containers. We have some pods and containers with elevated privileges, host network access, host path mounts, the ability to list Kubernetes secrets, so on. We can see here that a hundred and nine of our resources are not applying the correct community context to pods and containers. If we scroll down a bit more, we'll see that we have a hundred and nine images allowed from any registry

2:20 and a hundred nine containers or pods without a seccomp profile. In fairness, some of these are quite standard. Seccomp is not something that I see as widely adopted. But now that we have a target, a number to reduce, let's start applying those seccomp profiles even if you're just using the new defaults in Kubernetes one twenty three. Let's run a couple more scans before we dive into these in a little bit more detail. When we ran the first scan, we didn't specify any framework, so it was analyzing against all of them. However, we can say we want to scan,

2:50 Scanning Specific Frameworks

2:59 get the NSA framework in this directory. So depending on what your security posture is and which frameworks you choose internally to adopt, this will narrow the scope of the controls being used against your scan. It might make it a little bit easier to start getting those numbers down and improving your security posture. Now if we take a look at the extra code of this command, we'll see it's zero. It may be that you actually want to fill this because there's a severity threshold that goes against your service levels. Perhaps you don't want to allow anything with a critical violation

3:23 Controlling Exit Code with Severity Threshold

3:39 to pass your CI process. For this, we can add severity threshold, and we'll say that we want to fail on anything that's critical. If we echo the response here, we get a zero. Now let's run that again with hi. And you'll see that we have a fatal warning at the end of the command telling us that our threshold was met. And if we do an echo on the result code, we have a one. So this is a nice way to build a short feedback loop to know if various frameworks or controls are in violation of what

4:28 you're trying to adopt with your security posture. Speaking of controls, we can actually run Kubescape to scan for individual controls too. Perhaps we want to make sure that host paths are not used in any of our Kubernetes manifest. So how do we get the ID of that control? Well, we can run Kubescape list control, which will list all the controls available for us to filter on. We can then grep for host path. Now that we have the name, we can run Kubescape scan for a single control. I'm going to use host path mount, which is just the name of the control that

4:49 Listing Controls

5:16 we want to scan for, and then pass in our path. And here we'll see we have two failed resources that are using a control we don't want them to use. And as it says at the bottom of this output, simply a dash v to get more information on the resources themselves. Now we can see that our Prometheus exporter and Fluent d daemon are the resources in violation of this control. However, we know that Prometheus and Fluentd do need slightly more elevated access to the host, including host path nodes. It's the nature of what they do, So

5:49 Handling Exceptions (SaaS Mention)

6:00 you can log in to Kubescape SaaS like we did in the first video, add the exceptions, and we're good. These violations will no longer be present on the CLI. Let's take a look at two more features of the Kubescape CLI. Let's go into the Google demo directory. And you'll see here, we have a tree that is a customized directory. This is a set of Kubernetes manifest where we have a customization dot YAML. If you're familiar with customize, this will allow us to take a safe set of resources and apply some overlays, which means that when we're scanning these,

6:11 Scanning Kustomize Manifests

6:47 we can't just scan what is inside the base directory, the vanilla manifest. We have to account for the fact that the customizations may change or reshape those manifests. And Kubescape supports us at the box. If we run if we run Kubescapescandot, we'll see on the info login line that the scanner has started, and then we have this line here. Customizations are actually detected, scanning the rendered objects. This is important. It's important for Kubescape to understand that we don't just use vanilla manifest because those won't be what hit our clusters directly. And to confirm this works,

7:43 we can modify the customization file. We can see that we have some common labels, updates app, hello world, and app, hello world. Now when we save this and scan again, Our label usage for resources went from 25 to 13. Awesome. Now, Kubescape doesn't just handle customize and customizations, but also help charts. Here we have a chart on YAML and a templates directory like so. Now, of course, templates within a Helm chart could be straight up Kubernetes manifest YAML, but more often than not, they are littered and composed of many, many Go template string. But Kubescape doesn't mind.

8:25 Scanning Helm Charts

8:56 If we do a Kubescape scan, then we'll see that we have the same label, Kubernetes common label, failed resources. Only this time, the number is 12. So let's change the helm value style. And here, I'm going to add labels, k that, hello world, and app. Hello world. And run Kubescape scan one more time. We'll see that our label usage went from 12 to seven. Now that is because I only patched a few of those deployment. Yaml to actually use the new top level labels value in the values file. However, it's enough to confirm that Kubescape is rendering our helm chart before

9:52 applying the controls, and the same for customize. And that's pretty cool. So let's move on to the second part of today's demo. How do we integrate Kubescape into our CI process? It's all very well and good that I can install Kubescape locally on my machine, scan my resources, but it's 2022, almost 2023. We need to automate this. So we need to bake this in to our CI process so we get alerts for the controls that we care about the most, whether that be all the criticals or a certain framework or one or two controls that you never want

10:00 Introduction to CI/CD Integration

10:29 to hack your production cluster, that is up to you. So let's see how it's done. So here I am in the GitHub repository for the clustered automation. Why? Well, because in here, we have a deployment manifest. A config map, a service on a stateful set for Postgres, and a service for the clustered application. These manifests have not been written with security in mind, given that they're used primarily for a show in breaking Kubernetes clusters. However, why don't we set this repository up to take advantage of Kubescape in a CI environment? Now, until recently, you would have to orchestrate and manage getting

11:14 the Kubescape CLI yourself, running it against your code, and uploading the artifact on your GitHub release. But that's all changed from the first week in December. There's now a GitHub action that automates this entire process for you. So the first thing we're going to do is create a new workflow. We'll call this security dot YAML. We can give this a name and say security scanning or clustered manifests. We want to run this on push events and we'll do all of them and pull request. Next, we define a job and we'll just call this Kubescape and we're

11:33 Setting up the GitHub Action Workflow

12:09 going to say that it runs on Ubuntu latest. Now we have a few steps as part of this. One, as with all GitHub actions, we need to do checkout. Well, maybe we're going to use checkout b three. Now, we can use the Kubescape GitHub action on the latest version. Now at the moment, we don't want this to fail if there is an error, so we're gonna set this to true. Now we can configure the action using the with keyword. Now we can configure the format using the format key. How do we work out which formats are

13:06 supported? It's the same formats provided in the Kubescape scan help output. You'll see here we can use pretty printer, JSON, GA unit, Prometheus, PDF, HTML, or SADIF. Let's grab pretty printer. Next, we can specify the path that we wish to scan. For me, that's going to be workload opt Kubernetes. Workload opt Kubernetes. And that should be enough to get this started. So let's commit and push. Alright. Now we can pop over to the run itself, And we'll give that just a moment. I'm done. Now, that completed relatively fast because it's not really scanning much. And you'll see when we expand it, there's

14:07 Viewing Action Output (Pretty Printer Format)

14:28 also very little output that is available to us. And this is because when you specify the output format, Kubescape is going to write that format to a file. In our case, a results dot out file. We can come back to our action and add another step. So let's add a step so that we can see the output. Here, we can do cat result dot out. And we'll be nice and we'll give this a name, like so. We add a commit message, and we push. Now we can pop over to to our action where our next action has no running,

15:31 hopefully. Alright. We can open the results, and now the output from our scan is visible from all our action runners. Because this is probably not the best way to get started. Let's come back and modify the format to be JUnit. And now we're going to use an action for publishing g unit reports. And we can tell it to run with the report paths of anything dot XML. And now we can push this, and we'll see a new XML report added to our repository. Let's go back to our actions. Now we can see the JUnit report parser.

16:03 Publishing JUnit Reports

17:11 It's created a lovely report from all the controls. And what's even nicer about this is if we come back to the summary of this job and scroll to the bottom, we'll see the test report here where we ran 406 tests, 40 passed, a whole bunch were skipped, and we have 47 failing. So increasing the ability to understand, visualize the controls that are failing with our manifest. Let's take a look at one more improvement. Now we're going to change from JUnit to SARIF. What is SARIF? Well, it is the static analysis results interchange format. Easy. It is a common format used,

17:43 Publishing SARIF Reports for Code Scanning

18:14 especially by CodeQL from GitHub, for understanding the results of static static analysis scanning of code and other artifacts. So now we need to change the final step and remove the g unit uploading. So now that we've removed the g unit test, the g unit step, let's pop down. Thank you, Copilot. And add the GitHub official CodeQL action for uploading a SARIF artifact. You'll see here that it's set to SARIF file would be kubescape results dot SARIF. We can add the output file to the kubescape step and just ensure that the names match. We can save this,

19:13 write a nice commit message and push. And now when we go back to GitHub to our most recent run of GitHub actions runner, hopefully give it just a few seconds to complete, it will upload the SARIF file to GitHub code scanning. Finally. Now that took nearly two and a half minutes. However, it's important to note the Kubescape scan was very quick. The upload to code scanning is very quick. However, you may find there's a delay waiting for CodeQL to analyze the report. But now that that's finished, we can go to the security tab on our repository.

19:55 Exploring GitHub Code Scanning Alerts

20:01 From here, you'll see that code scanning alerts have been enabled. And when we click on a few of the alerts, you'll see something interesting. Our workflow security scanning for clustered manifest, which ran one minute ago, has opened 37 code scanning issues for me to work on, integrating the entire Kubescape process into your GitHub workflow. From here, we can click on one of them. It will show us the manifest where the control was violated. It gives us a nice error message and tells you how to remediate the problem. From here, you can choose to dismiss the alert as

20:45 Remediation and Workflow Integration

20:49 won't fix false positive or it's just a test, or you could create an issue for someone on your team or in open source land to come and provide a fix. So that is Kubescape integrated in the CI process with GitHub actions. That's pretty sweet. So there you have it. Kubescape on the CLI, integrated into CI, and even one step further, integrated directly into your GitHub development workflow. Go check it out. Have some fun. If you have any questions or any problems, leave a comment in the comment section below or reach out via Twitter. I can't wait

21:10 Conclusion

21:34 to speak to you. Have a great day.