 Thank you for attending this talk about the Kubernetes Command Configuration Scoring System, or KCCSS, in short. I'll start with the brief introduction. So my name is Julien Sobriar. I am now part of VMware since a week ago. I was in a company called Octane that just got acquired by VMware. If you want to talk to me or send me a question, don't hesitate to email me directly at jsobriar.vmware.com. I'll show you a couple of other ways to contact me later on. So a quick word about Kubernetes before we talk about security for Kubernetes. So the short definition of Kubernetes is that it's a container orchestrator that basically sits between your servers and your containerized application. The definition doesn't do justice to the extent of what Kubernetes does. So Kubernetes really is an abstraction layer for a lot of things. It abstracts your entire infrastructure. That's you define your storage provisioning. In Kubernetes, you define how you expose services to the other outsides, road balancers, or ingress controller, etc. It abstracts your entire network layer. It gives access to the containers where you can log into the containers directly. It defines what kind of privileges and access each container has. It redefines how users but also workload permissions are defined, how to manage your secrets. So it's really a wide area that Kubernetes redefines through its abstraction layer. And today we'll talk specifically about the runtime configuration of workloads. There are over 30 different types of configuration settings for your running containerized applications. Now, some have to do with isolations. Now, can our container actually isolated from each other or can they share the same P and not share the same IPC to communicate with each other? Maybe they share some of the file or system. Maybe they get some capabilities that allow them to do man in the middle so they can actually see traffic coming from other containers or even network sniffing. It's also, you know, some of the security settings or infrastructure security define how and what services are being exposed knows for load balancer, Kubernetes load balancer, but also, you know, using share host network binding the workload IP to the node IP using tube CTL command to basically poke a hole in your Kubernetes cluster and expose a container port directly to the outside. You know, all of that then can be, you know, managed for interest or agress policy from Kubernetes that you may or may not have set up. Integrity, you know, can the workload make changes to the hoses itself, through the file systems, through privileges, can workload even talk to Kubernetes. Maybe some workload are able to create their own part, their own workload or delete workload because they have the right API access rights and they have access to secrets and all the capabilities, your policies like second PC Linux that, you know, might try to prevent container escape. And if you add other things such as a service mesh, you know, you get a lot more settings that, you know, dictate the security posture of all of your containers. And with over 30 security settings, that means you have over a billion combinations. So how do you know, you know, out of these 30 settings, which one, which combination are more risky than others and how many of them are okay because, you know, some of these settings are cancelling each other. So for example, this, you know, a combination of having a load balancer that exposes services that also has privilege access, can create other other ports, you know, it is more dangerous. It's pretty easy to tell, but others, for example, you know, having, yes, being the ability to do network in the middle or network sniffing, but having a service mesh that do encryption will actually renegade some of it. But if you ask many of the dev apps or developers, you know, which one of your workloads are the more risky or why, you know, the answer will often be, you know, I don't know. I can tell you which one are running privilege, I can tell you which one are running as routes, but really doing these comprehensive security assessments is very hard. So that's why, you know, at OctoRyn, we wanted to give away for our users to be able to tell exactly which one of their workloads are more risky, where there is come from and help them remediate or mitigate these security issues. So we wanted to come up with the framework that will address that. And the first thing that we did is look around and see what were the existing security framework and whether we could apply them to these specific issues with Kubernetes runtime configuration. So you're probably familiar with a CVSS framework, the common vulnerabilities current system. If you do image scanning for Kubernetes, now the vulnerabilities are related with this framework. So it's a very good framework for describing the risk. You know, it shows what is the impact on availability, confidentiality, integrity, what's the scope of the validity, how easy it is to explore it. So a very good way to describe it. And you can already tell from the name of KCCSS, CVSS, that a lot of the inspiration came from this framework. And that's why we have a single name. And there are the same umbrella as CVSS. There was actually an attempt to apply CVSS to configuration files. And there was a framework called the common configuration scoring system, CCSS, that was an adaptation of CVSS for configuration. Unfortunately, this project is pretty old. It's based on the older version of CVSS version 2.0 right now, similar version 3.1. And it did not take off. But it showed the potential for being able to apply this CVSS framework to configuration and not to vulnerabilities. And finally, the last framework that we looked at that was very inspiring for us is the CC, the common configuration animation. And here's the difference is it's actually a checklist that a DevOps person can go through to make sure a software on OS is configured securely. So it's a list of checks that should go through one by one and make sure that all your configuration file settings are secured properly. So we basically took the best of these frameworks. Now, we created a list of rules inside KCCSS for each of the security settings. So just like CC, we describe this rule, this phrase the same way as CVSS. And I'll go into more details very soon. And obviously, they apply to configuration settings, not turn it up. So just like CCSS. So we took a combination of the existing framework. And what we did is we made it specific to Kubernetes. And also, we created a way to aggregate this individual risk for each rule to be able to compute a risk for the entire workload. Because in the end, what we want to show is what is the most risky workload. So I'll get into more details about the framework and the different rules. So we have two types of rules. The first one is a risk. So every configuration setting that can introduce a risk is described the same way as the CVSS. So we show what is the impact to integrity, confidentiality, availability, from non-low, high, with a good description that should really help anybody who is not a security expert to really understand what are the actual risks that they are potentially running or exploiting themselves to in their Kubernetes cluster. Then just like CVSS, we show how easy it is or not easy to exploit that vulnerability. So we have a rating for the exploitability. Is it something very complex? Or is it something that anybody can do with tools that are available out there? The attack vector, is it a remotely exploitable risk? Or does it require local access? And what is the scope that we made specific to Kubernetes? So can you, with this potential risk, can you impact just the workload that's running? Or can you impact potentially the that's where the workload is running or the entire cluster? So along with the risk, we have a different type of rule that we created that does not exist in CVSS, which is a remediation. And that's a security setting that improve or remediate some of the existing risks and lower some type of existing risk. And we describe it in a similar way as to CVSS. So does it lower the risk on integrity, confidentiality, availability? How does it do it? Does it remediate remote or local attacks? Does it help remediate issues within the pod itself or maybe the entire cluster or the node? So very similar to the way we describe risk. So the first node, half of the framework is this list of rules which contain risk and remediation. Now the second part is the formula that will create this risk code for the entire workload. So how does this work? First, we start creating a risk code for individual risks. So we map a workload with no zero to 30 something, some series that may apply to the workload. We create a risk code from zero. That's the lowest risk to 10 highest risk. And it's very similar to the CVSS formula. We basically take the impact of the risk on one side. And on the other side, how likely it is to exploit it and what is a potential blast radius of exploiting this vulnerability. And we added two of them and that gave us a score from zero to 10. So first step, we create a risk code for each individual risk in the workload. And then from this list of individual risks, we came up with a new formula and it's not something that exists in CVSS, which only rates individual vulnerabilities and not the security of your overall software. So we look at similar risk. So for every risk that have the same attack vector and the same scope, we take the highest risk. We add them together, take the square root and that gives us a risk of from zero to 10. So that means with this formula, if you have many risks that impact different criteria like availability, integrity, and confidentiality, we have a higher score than maybe 10 risks that are all impacting only the availability of your cluster. So you may have noticed that I talked about risk, but I didn't mention remediation. And the way we use remediation is when we look at each of these individual risks for workload, we look for corresponding remediation. And we basically, if you have a matching remediation, we subtract the remediation from the risk. So quick example, we have a risk that has a high impact on both confidentiality, integrity, and availability. If we find a matching remediation, right now it means remediation that has the same attack vector and same scope, and has in this case a low impact on confidentiality, high on integrity, and none on availability. We subtract it and we get a new risk that's lowered by the remediation. And we actually use this lower risk in our formula. So the remediation impacts the individual risk, which then will have an impact on the overall risk. So KCCSS is a framework. So how do you actually use this framework? It's not very convenient to look at the different rules, try to map in yourself. So because we wanted as many people to be able to try KCCSS easily, we created an open source implementation of KCCSS. We call CubeScan. And CubeScan is an open source container that you install in your cluster. It has the KCCSS framework. It scan your running workloads and show you the results in a nice web UI. And what's important here, it's really looking at the runtime configuration of your workloads. So you may have workloads, no definition in your YAML file that you install in your cluster, but then you may have other types of API calls, operators, no manual changes in your cluster. Hopefully you don't do too many of them. But that may change how the workload actually configured. And because we are looking at the runtime configuration, we are really looking at the current state of your workloads. It doesn't matter if you have anything making changes. No, we will see the end results. So let me show you how the CubeScan output looks like. I'll show you a quick demo. Actually, before I show you CubeScan, I wanted to show the key repository for both KCCSS and CubeScan. If you do Google search for GitHub KCCSS, we'll find this repository, which has all the rules, risk and remediation, and also the formula, which is exactly how it's being completed. You also have a lot more information, a lot more details about the goals, about how it's different from KCCSS, from CVSS, sorry. So take a look at this page. Take a look at the at the Wiki as well. We have more information there. We can go into more details. Same thing for CubeScan, such GitHub CubeScan. And you will find this page that describes what CubeScan does, and more importantly, shows you how to install it. So you can, of course, compile everything from source. It's fully open source, but we have uploaded, we have, sorry, we have, yes, we have uploaded the Docker images into registry. So you can just copy and pass these two commands to be able to install it in your cluster. And there's two ways to install CubeScan, one, which is probably the safest way, which is to not make the web UI accessible to the outside, but do a CubeCtl port forward. Remember, I talked about this way of making a hole into your Kubernetes cluster to expose the series, so you can do that to make sure that nobody has access to it. Or if you want to share it, you can put your, the web UI behind a load ban series. Just choose whatever method of installation you want, and just copy and pass two commands, and you will see something like this. So this is the latest version of CubeScan. We did, we released a new version less than two weeks ago. You can see it's still the old octane. So what you see here is the risk assessments, no, from the KCCSS framework for all of the workloads that are running inside your cluster. So it works with one cluster only. So if you want to show the information on different clusters, you just have to install CubeScan. So you can already tell, no, that actually doesn't look too bad here. We have two high severity seven, so it's not too high either, and mostly medium otherwise. So we can already know, know which one are maybe of concern or not. And then you can drill down into where there is actually come from. And here you see that there are a couple of things that are interesting. So one, we see that this workload does high local privileges. So it might be running as road, and it is privileged. We also see that it is exposed through load balancer. So it is possible to get to this workload remotely. And now, you know, you can see that there is a combination of local risk, but also remote risk, change together. And once you get access to it, you can actually do a privileged relation. You can go into more details now by clicking and show more. And that's where you have the full information. So you can see that here, you know, that's obviously exposed to the outside of the communities now. So it's remotely exploitable. And it's changed with being privileged. That gives no biological access, but that you might change with a remote remote explorer. So you can get into, you know, read all the details, understand what is your actual risk, and understand what you want to do about it. We can see here that there's actually one remediation. And that's about encryption, because it's a light service mesh mock time that provides encryption. So this remediation will only impact remote risk that have something to do with being able to see traffic. And there's actually one here. Find it. I guess it's not here. Oh, yeah, it is here. So the file that can do that, this workload as network capability means it can create any kind of packets and might be able to do some kind of manual attack and see some of the traffic, but because of the encryption, that will actually do whether it's here. So you can see, you know, you can go through them one by one. I think it's very useful to do a quick round of CubeScan and see where you stand. You know, you might be surprised that you have some high severity workloads or, you know, might make you see better at night, saying that the risk is pretty low for your cluster. Go back to the slides. A few words to conclude. This is just in case of demo failures and screenshots to be able to show you. So what's coming next? So we are very excited about KCCSS. We use it in the product and we see that it resonates with people. Whenever you see a risk, the first question is how did you come up with that? Do I agree with the way you do the risk computation? So it's very good. That's why we want it to be open source and we hope more people are going to contribute to it. There are definitely improvements that we are already working on. So one of them is a better matching of remediation and risk. Now I mentioned that right now we're looking at the scope and the attack vector, but we've added more classifications of more granular classification of risk and remediation that allow us to do a better matching between risk and remediation. Now you can, again, go to the KCCSS GitHub repository, look at the rule and you will see this additional information there. We also are going to release a new formula for the overall workload risk. So again, that was a formula that we came up from scratch. We are going to change it a little bit. So we have a wider range of risk. We did add a lot of new rules recently, especially around our back and around workload having API access to Kubernetes to look at secrets, to create pods, etc. So now it's part of the framework. And one thing I'm personally most excited about is being able to use KCCSS as the way to understand how you can reduce your risk. I want to provide some tools so once you see your risk or you can say, okay, what will happen if I fix this one? That's maybe easy to do. Does it reduce my risk a lot? Or does it doesn't do any much change because I have some other similarities that I'm not addressing? But also, what are the mitigation that are available and that might be easier than just making a privilege, content or non-privilege, which might be, in some cases, not possible. So instead, what are the mitigation that are available to me that maybe I could use to reduce my risk? And finally, more references now. So we started to add references to the CIS benchmark. So you can see which one of the secure risk have a CIS benchmark for Kubernetes item. We also apply the Mitre attack framework. And by the way, this very interesting blog post for Microsoft that created a Mitre attack framework specific to Kubernetes. And that will show you remember, I showed at the beginning of the talk with the extent of the Kubernetes layer, the fact that you define so many things inside Kubernetes that the attack surface is huge. This attack framework, all Kubernetes shows that there are a lot of different attack vectors for Kubernetes that you may not have thought about and a lot of them actually about this security setting that I mentioned. So we are working on adding all of this to the framework. So make it richer, make it easier to get third-party references from CIS benchmark and other into it and really have it to be very powerful, not just to know what's going on, but how you can leverage that to reduce your overall risk. So why did we make it open source? First, the fact that we took inspiration from existing open source framework, now it's just natural that we wanted to make it open source as well. We also deliberately made it separate from CubeScan because I feel it's much easier for especially non-developer like me to be able to contribute to a framework and not be required to know how to code. We hope that other tools are going to use it. We're looking at a couple of open source policy agents that we could integrate with so that for each settings, for example, you have a policy to be able to catch it in remediates. We also hope that open source solution but also vendors will add their own list of rules and remediations. Now, if you have a part of Istio, for example, we added a couple of rules or how Istio remediates an issue, but you could add to it if you have a security solution or Kubernetes, now you could add rules there. So we're looking for more information. And finally, again, if you want more information, go to the GitHub, Octarin.sec repositories for KCCSS as CubeScan and actually take a look at other projects we have there that might be of interest to you, also open source. One of them, for example, is Mod Security for Envoy. But we have a few other things for Kubernetes that might be interesting to look at. And finally, if you want more information, now we haven't moved everything from Octarin to VMware yet, so just go to the Octarin.sec.com website. Now at the top, there is a tab about resources and you get this CubeScan page that gives you also a good overview of what CubeScan does and the KCCSS framework. Thank you. Again, don't hesitate to contact me if you have any questions. You feel free to contribute directly on GitHub if you have any questions, any comments, anything to add or anything. Thank you. Thank you everybody for attending the talk. So we'll go to Q&A. I don't see too many questions. There is one about the capabilities, asking why I only have two capabilities. I guess it's on one of the slides. Let me see if I can get to it. So yes, I mentioned two of the most used capabilities here. But yes, there are certainly other capabilities that have consequences about the security of your workloads. I didn't list all of the rules that we use in KCCSS and certainly others, but that are probably the two capabilities that we see used the most even when they are not really required. Another question about what would happen to CubeScan under VMware as an open source project. So VMware has a lot of open source projects, so we hope to move CubeScan under VMware and keep using it. KCCSS is very useful for us. It's a framework that we use and having a way to demonstrate it easily with CubeScan is very useful even under VMware. So we're working on moving that under VMware and keeping it open source and making updates to it. So if you have any questions, don't hesitate to add them to the list. I just want to remind everybody that you can also send me emails directly. If you try, for example, CubeScan and have any questions, you'll find references in the GitHub repository, but maybe this is your jsoprior at VMware.com. There's no other question. Yes, I just want to reiterate that installing CubeScan is very easy and just two comments to install the container in your cluster and then there's another comment to delete it when you're done. So let us know if you have an issue when it should be very easy. We know a lot of people who've tried it. It works in all kind of Kubernetes clusters, whether it's on on-premise, in the cloud, managed or not. So it's very easy to give the try. If there's no more question, thank you everybody for listening to the talk and don't hesitate to contact me if you have any questions or anything you want to do.