 Hello everyone and thank you for joining me for this CNCF on-demand webinar on Kubernetes security single pane of glass. The tool that we will explore today, the open source that we will explore today is called Cubescape and what I will try to show you is how you can use Cubescape to overcome the increasing complexity of Kubernetes security across all the different things that can go wrong for misconfigurations to vulnerabilities, role-based access control, secrets that may be out there, network policies and more. The idea is to see across all the different things and get an holistic view of what's happening in and across your clusters. We will be happy if you star us on GitHub and Cubescape is a fast-growing project and we would love you to take part of it. You can join the discussion on our Discord or you can visit us on our website to learn more about Cubescape and our roadmap and what we plan to do with it. Just a little bit about myself. My name is Shahuli. I'm the CEO and one of the co-founders of Armour. I'm a software developer turned into a manure and today I really enjoy my life. I wake up in the morning and go surfing. Then I go and I build Kubernetes security products for the rest of the day, go back home, put my three kids to sleep and repeat. A lot of fun with the kids and with my life and I really enjoy it and that's just great to be here and share with this community what we've been building. What is Cubescape? Cubescape is really becoming one of the most popular Kubernetes security open source tools out there on GitHub. Getting great reviews in GitHub and ready to hack and use from our users, gaining a lot of stars and really blowing up in terms of the number of stars and followers of the project, which is something that we are super, super proud of. But what does it do? The idea is very simple. It's to get very quickly into a very deep and good understanding of what is going on in your cluster. So you can go to GitHub. There's a one line install script that you can use. You get your results. You go to the Cubescape portal, which is a SAS version that we've deployed for you, which gives you a single pane of glass across all of your clusters and you can choose to add Cubescape to your CI CD and find issues early on and avoid delays. But you can also add it to your cluster to get continuous security, to get drift control and continuously monitor your posture on an ongoing manner. When you make the decision, if you put Cubescape in your CI CD, it basically runs as a CLI within your existing DevOps tools in your CI CD. We have integrations with GitHub, GitLab, all of the Jenkins, SQL CI, all of the different pipelines and tools that are available. And also you can put Cubescape as a crown job and a simple namespace in your clusters for continuous monitoring if you wake up and do the scans for you and continuously identify whether drifts are happening and give you results over time. If you think about what is creating a single pane of glass for Kubernetes, what does that even mean? It basically means taking all of the different things that can go wrong and collecting them together and give you and enable you to define and enforce best practices across them based on pre-built frameworks and best practices that are there in the industry and standards. This also goes to compliance, enabling you to identify and prevent drifts continuously from your CI CD to production across all of those elements and then enabling you through remediation and recommendation and contextual insights because you have this single pane of glass to continuously tighten your environment. And when we think about the data or the elements that go into what should go into a single pane of glass, it is the different configurations of your Kubernetes, the cluster itself, the configurations of your workloads and deployments, the actual user activity which can be taken from the audit log, vulnerability assessments of all the images and software running in your environment, the different RBAC role-based access controls that exist in your cluster and whether there is some excessive privileges that shouldn't be there and finally taking all of that against compliance benchmarks because this gives you a very structured way of understanding the risk and the posture of your cluster. So that is what we are aiming to do in Cubescape. We are going in that direction and we already have a lot of that installed. I encourage you to look at our equipment and see more and today I'm going to show with you what we have to date and how you can use it to get single pane of glass security for your own clusters. When we look at today, basically the idea is that we give you a risk analysis and compliance across all your clusters. We visualize your RBAC, your role-based access control and enable you to query it and understand in a very informative way and to investigate what's going on with the different roles in your clusters and image scanning of the actual code running in your clusters. So it's not just in the repository, it gives you an actual view of the images currently running in your cluster and what your current risk is in the cluster and we do it across regions, we do it across providers. We are pre-integrated with GKE, AKS, EKS and OpenShift. We are partners with all of those and you can actually use and take it to any one of those environments. So this was theory but let's show you in practice what does this look like. If you want to get a single pane of glass, if you want to install it and run with it, what does it look like? So any travel, any journey that you take with us starts with our Github page where you basically take CubeScape and install it in your cluster. Let me show you how you do that. So I go to Github, you have very detailed information in Github about our control and how to install it and here is the installation line. It's basically an installed script that downloads the latest version of CubeScape as a CLI to your cluster. I'm going to copy that and of course it is all open source so you can see exactly what this install does. I'm not trying to get you to run install into a pipe of bash, similar like without knowing what's going on you can completely read it but I've read it and I know what's there so I feel free to run it in my cluster. I have here a GKE cluster, I'm just going to run this command. It basically downloads CubeScape into my environment and now CubeScape is installed. Right now it is running on this computer, on this cloud shell and it will be pointed. It will ever cluster the Cube CTL, the CubeCutter is currently pointed at. So if I do CubeCutter get pods, I will go through the GKE authentication and I see that they have an Ipster application running here. It is the Google shop, the Google Ipster shop microservices demo that we're running. You can see that some of it is failing right now but this is not of interest to us at this point. Some of it is out of CPU and let's run a scan. Let's see what's going on in this cluster because there is much more going on in this cluster than just this Ipster. There is the namespace of CubeScape system as well and maybe other things that are installed here. All I need to do is do CubeScape, scan and I'm going to choose framework NSA just for the sake of it which will basically test my cluster against the NSA guidance for Kubernetes security. We will let it run and I get a summary right here in my STD out of the status and the risk of my cluster. You can see that some of the tests have been skipped. The skip test are control plane tests that if you want to run, you need to enable specifically or host level tests that require us to put a temporary demon set on your host and we do not want to do it by default. We want you to enable that with a specific command. You can see here that if you do want to do that, you're going to need to run a CubeScape. Where is it? You can see it in here. You need to put submit if you want to upload it and you can let's see host. Yeah, minus, minus enable host scan. This is the flag that will actually scan all your hosts as well and then all of those tests will not be skipped. I got that. I have a view of my cluster right here in my STD out. I can actually export it directly to a JSON and put it as part of my CI CD. Now, let's go and see the single pane of glass as it is described in the UI of CubeScape. You get a link right here to the UI so you can actually go directly there but I'm already registered so I'm going to go directly and show it to you. So this is where you get to and you can see I see all of my different clusters. I can see my risk across all of the clusters that I have and some of the clusters that I have here for longer time. I also see the risk over time for that cluster and I can also see it against different frameworks. I will go into this cluster just for this demonstration. Now, what we have here as a single pane of glass is now I will basically be able to see my cluster across different elements of security of Kubernetes. So we have three tabs here which you can use and we're also always enhancing it and I have a section at the end of this session where I'm sharing with you our roadmap and where we want to go and we would love to get your comments and thoughts about new ideas of what we can do to make this tool better. But as for now, let's look at what we have here and the different aspects of security that you have right now in CubeScape. The first tab is about the risk. Risk is basically configurations. This takes into account all of the different parameters of what's going on in your cluster and gives you a very clear view of the risk in your cluster. It puts into account misconfigurations. It takes into account vulnerabilities and it takes into account role-based access control. All of that is driven into the risk level and the risk is built on different controls. So we have in the different frameworks we have different controls that we run against your clusters and some of these controls may just be configuration but some of these controls may be correlating both for example a misconfiguration and a scanning problem. So for example a very legitimate control would be let's not have misconfigured highly privileged containers that also have critical remote code execution vulnerabilities in them. So this is a control that actually brings together a few of the assets that I've talked about before configuration, vulnerability scanning and RBAC into a play where you can prioritize it and give it higher and higher severity and things that you need to take care of. If we look in usually when I look into the different controls that fail in my clusters I like to organize them by severity and look at the critical ones first. As you remember we skipped the control plane type controls and this is just because anyone should do all the integration at this point but it is very simple and you have instructions on how to do it if you would like to for GKE, for AWS, EKS etc. When I look here I see that just as an example that I have one of these tests that they've failed application credentials and configuration files. So we have a developer that probably forgot or put because they thought it's going to be easier for them. The application credentials something is secret in the configuration file of the deployment. So this is something that we should take care of and just the next one is look at that privilege container. Basically someone is running container as privilege which is definitely not the best practice. If I go into this I can see that actually I have more than one privilege containers running. I have nine of them but eight of them are actually in the cube system namespace and these are already set up as exceptions. We recommend you to put those in exceptions and the system can do it for you and the idea is that you have nothing to do about that. Frankly the cube proxy and all of the different cube system pods they need to run as privilege in order for the cluster to operate. So no need to go and fix them but this recommendation service that's a different story where you want to check what's going on there and you can see here that you can go directly into that deployment and understand what is wrong with it. So if you look at that we see that in line 69 we have privilege container. We're going to go there and to take us directly to the problematic line and we'll show us exactly how to solve it. Going forward in the next editions of Cubescape we would like you to be able to see a diff view of the fixed and the error yaml and you will be able to accept the fixed version and even create a pull request directly from here to your git in order to fix it back in the CICD. So your next update you're going to have a complete and solved version of this microservice. Another thing that is super helpful for users of Cubescape is that you can take all of those control and frameworks and embed them into your CICD in a customized manner. Customized manner means that you can create for example a policy that will run in your CICD for the development cluster and another policy that will run in the US or another policy that will run for one product or another product. And you can create those policies you can create as many policies and as many frameworks as you would like and you can deploy them and you will see them all in a single screen. You can see that I already have here like Shaoli corp one and my custom framework here and I've created all kind of frameworks that I use in different places in my organizations in my organization and it is very easy for me to create one. If I go to frameworks here, customize your own framework, I get into a screen that enables me to create my own custom framework with whichever control I would like to have. So let's do and Shaoli custom framework and I'm just going to say demo for CNCF live webinar not live, it's not live on demand webinar. And now I can choose the controls that I want to have and I want to deploy in this in this in this framework. For example I can say okay privilege is something that I'm concerned about. So I'm going to not allow port forwarding privileges or I'm not going to allow my developers to put privilege containers or OSPID APC privileges or allow privilege escalations. Also I like them to put limits. So I would ask them to put CPU limits and memory limits in every email that they deploy in every workload that they deploy here. And I also don't want them to use. Well let's do just that. I'm going to click apply and I have my new framework here. It is here and now I can put it anywhere in my organization. I can use integrations. I can just install it on any cluster. It is automatically deployed to any cluster or any CubeScape that is already running in your environment. But if you want to put it back in your CICD you can take for example, let's take GitHub for example. You can go and you can see the very simple instructions on how to edit to GitHub. I clicked on the image. Here we go. You can see here the very simple example on how to create a GitHub action that will check any update to the YAML against this custom framework. All you need to do is change this NSA to the new custom framework that you have created. So this is how you get the control and all of the good things that CubeScape gives you because all of the different elements from vulnerability scanning to ArbaControl into your clusters in a very, very easy to use way. If you remember before in the beginning when I shared the presentation I told you you can use CubeScape in your CICD just like I just showed you or you can use it for continuous scans and continuous posture control of your cluster. It is very easy to do that if you go back to our settings and you go and you can see all your clusters. You can also add a new cluster and when you add a new cluster you can choose whether you want to edit to your CICD just like we did before with this installation script and then just running it with your account ID so you will see the results here or you can use our Helm repo and very easy Helm installation to add our namespace into your cluster and that namespace will regularly and you can actually configure it, scan your cluster for vulnerabilities, ArbaControl misconfiguration brings everything here into the single place where you can monitor all your clusters and all of your environment in a very easy to use way. If you have any questions about Helm and how to use that and how to install please reach out to us. It is literally a copy and paste of those three commands into your cluster. So that's the first that that's single pane of glass but what is it composed of? So we have all of the different controls that failed. How do we see and what do we see in terms of vulnerabilities? So Kiebscape automatically integrates with the repositories that are connected to your cluster. Let me go to your scanning. They just literally updated the production version as we speak, right? You can see that the risk will change to configuration scanning and you can see that we have a new so you got it live. You have a new updated compliance screen right here but let's go back to our to our demonstration and we will look at image scanning. So image scanning you can see basically we have a scanner running within your cluster. It pre integrates with the repositories from which your cluster is pulling images and it only looks at the images that you pull and that are running and are deployed in your cluster. So you can actually understand the vulnerability situation of your cluster right now what is running right now in your cluster and we divide it by critical high, medium and mobility is very very standard. We can show you exactly which of the vulnerabilities have fixes so 28 out of those 57 critical vulnerabilities actually have fixes. You can upgrade to a new version and we can also show you which ones are RCE remote code execution vulnerabilities are more problematic especially if they exist on an outbound facing ingress and workload because they can be actually abused without having access like all through the network. So this is super important to understand the know and we can filter and see only the critical vulnerabilities and see them here and then go directly into specific for example let's take the load generator here for example I can go into it and I can see how well here everything is negligible and medium but we can see everything and all the vulnerabilities that exist in this specific image and you have a view of all the images across time in your clusters. This is where we started to do it and you can see I didn't do anything and then change my cluster so you can see it running here. Next, the final part of our view and our overview of what's going on in your cluster is the role-based access control. The role-based access control visualizer enables you to actually see what's going on in your cluster in terms of role-based access control. The default view shows you not all the roles because if you were to show you all of the roles it will be and all of the role binding and verbs and the resources it will be a graph that you would not be able to manage. This is how complex RBAC really is in your clusters. If you just use GKE for example just the default roles and permissions that GKE creates in your clusters are quite extensive. You might think you might have just a few roles but you wouldn't believe how many roles you might really have in your clusters. You can see exactly which subjects have access to which resources but it is sometimes hard to investigate it if you see everything. Sometimes you want to focus just on a specific part of what's going on in your cluster. We've created for you built-in queries, popular queries that we've seen users using and we added them to give you a very easy way to understand what's going on in your cluster. Just as an example one of the very popular searches is who can exec into a pod because if someone can exec into a pod they can run code on that pod. We can see that in our case there is these are the pods. There is a role which is called common webbooks. It's an automated GKE role and there is a user common webbooks that can actually do anything literally anything to pods. Now I'm not sure you know whether I want the GKE common webbooks to have that type of access. It really depends on what that role is doing but in general this is something that I need to look into and maybe reduce and then I also see that I have the cluster admin role that as an admin can do anything on any resource and that is just how Kubernetes works but I see that the system masters group and the user system storage and the version generator, version migrator have admin role in my clusters. This is probably okay. It is good that I don't see any user here like Jonathan for example with cluster admin rights on my cluster so that's good. Another very popular query is unassigned roles. Unassigned roles are basically garbage. There are roles that if a user or if an attacker gets old of and can assign himself to those roles will be able to do things in your clusters and you don't want them. It is just a best practice to eliminate and the users less unassigned roles as possible so here you can see them very quickly and investigate what you want to do with them. Another one that is really nice is the port forwarding. You can see all of the different port forwarding capabilities in your clusters. I'm not going to go deep into that but you can see everything that's going on there. Now of course you might also want to have your own investigation of your cluster role-based access control privileges so you can clear the list and choose to do an investigation. An investigation basically brings you this floating investigation pane where you can now decide what you want to put on the map. Let's take as an example secrets. I look at secrets and I can see that secrets and of course there are resources in my cluster and now I can see all of the different roles and what they can do on a resource. For example I can see that this role can delete, get, list, watch through the API any secret and that's the cube system that is perfectly okay. We have the system controller here. We have the GLBC and we have all of those roles which are actually kind of interesting. This role is a bit interesting so what is this edit role and why can it do create, delete, etc. to any secrets. Let's see which subjects. We see that there are no subjects attached to this role so no one is really using this role but if someone was using this role I would say okay who this guy is, who this role is, what the subject is, why do they need this role but this is even worse or maybe something that you investigate why do I even have this role in my organization. Of course there's the admin that can do anything they want to the secret and again there is no subject created to this admin. Please bear in mind that this is not the class to admin, this is another admin role that I am in my cluster. This role for example they do have a subject. Let's look at all the subjects so we can see that this subject can use this role to get secrets in my environment and this is actually pretty much a standard. The Qt system of course needs to do that but this is the way you can actually investigate and see exactly what's going on in your cluster and then you can clear and do any investigation you want all over again of course. So this is the way we build the single pane of glass. We take the RBAC data, we take the image scanning data, we take all the misconfigurations and we take them together into a single risk pane where you can understand what's wrong with your cluster, you can do the cross clusters and the cross clouds. The compliance is another thing and I'm going to show it to you as you saw it just came out of the oven it was literally updated and our production was updated with this feature as I was recording this webinar. What we're doing next is taking this single pane of glass to the next level. We're going to do and our roadmap is built of several things that are intended to help DevOps and to help security architects get a better understanding of what's going on in their clusters. If I go back to my presentation and I'm going to go to overview of what's coming next this is where we're going so we need of course a lot of time and work to do that and we need a lot of support you can ever you can see on the roadmap publicly available on our Gita page but we want to take you from CI CD to continuous portrait control and even to random security bring all of that together into a single pane of glass to see what's going on in all your clusters and what's coming up really really soon is the single pane of glass dashboard which will basically take all of the information we have prioritize it for you and give you a very clear view of what's going on in any one of your clusters so here on the left hand side you will have all of your clusters prioritized already by the risk that is calculated based on all of the things that we talked about your role based access control your misconfigurations and your vulnerabilities and if you're over one of those those clusters you will see exactly the score you've got against the default framework all of the vulnerabilities that exist and you will be able to go directly here to analyze your role based access control and then of course you have the configuration risk and the vulnerability risk right here in a single place and a prioritized list which we call my work that will help you understand what you need to fix first and these are the things that you need to attend to in the most agent of ways and it will use it already it's already using prioritizing based on the context of each issue and again context goes to not only configuration but also vulnerabilities role based access control and in the future data that we're going to bring from your runtime environment so this is a summary that we're going into and we would love you to take part of you know building this you know go to our GitHub create a poll request see what we're doing look at our roadmap and you know we're looking forward to taking it even further and and that is it you know we're done and we would love to keep in touch you know let's connect you can connect with me via email you can link to me I would love to be in touch you can follow me on twitter I will probably follow you back I really enthusiast in twitter and you have our of course Gita page would love you if you star us enjoy the discussion on our discord or visit us it will I'm Shauli again I'm the CEO of Armo and the creator of Cubescape we are very excited about Cubescape we see it going places we want anyone and we want to help any developer any DevOps engineer or security architect to be able to understand the clusters very easily via this open source contribution tool that we've created yeah and that was it I hope you enjoyed it I hope I didn't bore you too much and please ping me and ping touch let me know if anything you might need we love love love to get feedback thank you so much