 Hello everyone and thank you very much for being here today for yet another CNCF webinar about how we at RML are leveraging chat GPT to create custom security controls. You may be asking yourselves, what are security controls? So security controls define rules that restrict access to resources, they verify the correctness of configuration settings and they detect suspicious activity. There are two CNCF projects that can be used to create policies. These projects are OPA, the Open Policy Agent and Kaverno. While they share some similarities, there are also some significant differences between them. Let's go over a few. The policy language for instance, OPA uses a language called Rego, which is declarative. It's a rule-based language that allows developers to write policies using a set of predefined rules and Kaverno on the other hand uses YAML-based policies that can be easily understood and written by Kubernetes users without a deep knowledge of programming languages. So while Kaverno is easily accessible to anybody that ever wrote YAML, OPA with Rego requires a learning curve. In terms of policy enforcement, OPA is a standalone policy engine that can be integrated with other Kubernetes tools such as Kubernetes submission controllers. It's used to enforce policies. Kaverno is a native Kubernetes submission controller, which means it integrates directly into Kubernetes API server and enforces policies in real time. The policy scope, OPA policies can be used to enforce policies across multiple clusters while Kaverno policies are scoped to a single Kubernetes cluster. And in terms of policy updates, for instance, in OPA, policies can be updated on the fly without requiring a restart to the policy agent. In Kaverno, policies need to be applied as a Kubernetes resource and they may require a restart of the Kubernetes API server. And lastly, in terms of management, OPA provides a comprehensive policy management API which enables users to manage policies programmatically. Kaverno, on the other hand, provides Kubernetes native policy management experience, where policies are managed as Kubernetes resources. In summary, while OPA and Kaverno are both policy engines that enable policy-based governance of Kubernetes clusters, they differ in their policy language, the enforcement, the scope, the updates, and the management. The choice between the two will probably depend on the specific use case and it is possible to use them both in conjunction to achieve a comprehensive policy-based governance. At RMO, we have the largest library of security controls available. There are over 200 at your disposal and they are all written in Rego. From time to time, RMO platform and Cubescape users want to write their own custom policies and controls to meet their specific needs and security policies. And to do so, they need to know how to use OPA and Rego, which is insintrivial. So this is where AI comes in. RMO Labs has harnessed GPT-3 to help users create their own custom controls without the need to know how to use OPA and Rego. All you need to do is to write what they want to check in natural language. And RMO with GPT-3 will generate the exact control written in Rego with a description and also the suggested remediation. Once the custom control is generated, the user can download it and run the control in the CLI as part of improving their Kubernetes security posture. So how do we do it? Let's take a look at RMO platform. All you need to do in order to use this feature is just head over to the settings page, to the control section, and click on Create Custom Control. Here you type what you want the control to test in plain English and it's that simple. That's it. You can also provide an example object to test the test should run on. For instance, you can put a deployment manifest or a secret manifest or whatever. And if you know exactly what you're looking for and what you're testing in this control, you can also provide the description and the necessary remediation, but you don't have to do that because RMO does that for you. Here I'm going to give it a name. It's going to be pod test. And what I want this control to test is I want this control to fail. If a pod, for instance, has a CPU resource request with a value higher than 300. Now after the control is created, you can use it right away. You can download the control to your machine and you can use Cubescape Scan Command in the CLI in order to test the control against your environment or your manifest files. Now I want to show you RMO platform in general and how the context is being connected. The first thing you see when you start using the RMO platform is the dashboard. It's a single view of everything you should know about your Kubernetes environments from CI CD and clusters and it's all aggregated into one single view that helps you focus on what really matters and what's really important from a security compliance perspective. What we see here are the different clusters that I've scanned in the past and it's prioritized by the risk score calculated based on the different framework we use. And you understand which cluster you should start working on first, right? We also show you configuration risks trend over time so you can identify drift changes in your configuration so maybe you notice something changed and there's maybe a spike in the graph so you need to pay attention to it and you need to take action about it. Also when it comes to vulnerabilities you can see right here in the lower graph and we also show you what are the top five failed controls that we ran against your environment and what are the top five CVEs that we found on your clusters. This is actionable items from the dashboard screen. Now this is usually the first view that a typical user sees after the onboarding and this is where you should start your Kubernetes security journey first thing in the morning. The solution of RMO platform is focusing on two main areas. One is happening inside your cluster and also on the outside of your cluster. So let's talk about compliance. What you see here are different clusters that I've scanned and you can see which provider the cluster is on and any other information that we provide. We support managed and unmanaged Kubernetes clusters like AKS, EKS, GKE or any unmanaged Kubernetes type that you are using. And if I want to, when I dive in to one of these different cluster scans reports we see the different controls that the system tested and which of them failed meaning I need to pay attention to. And before I dive in I would like to explain how we manage the controls that we just talked about according to the different frameworks. So let's navigate again to the settings page and under the framework section you can see the different frameworks that we have. We have out of the box frameworks like MITRE, NSA, CAS and there is also an option to customize and build your own framework and cherry pick the controls that are relevant to your security needs and to your compliance requirements. Each framework consists of many types of controls meaning tests that are being tested against your environment. And currently we support more than 200 controls that are Kubernetes specific that you'll be able to run inside your environments. Some of the controls can be configured according to specific needs. So let's say I look for application credentials and configuration files which is of course not something that is recommended. It's not recommended to save secrets in your configuration files. And I can decide on which secret the control should look for. I can add or remove different types of values and this is also true for other controls that may be configurable in the platform. And this provides a high level of flexibility and customization. Let's navigate back to the platform and now I will navigate to the compliance section. You can run scans manually or according to a schedule interval using ChromeJobs. Focusing on the control that we just looked at the application credentials, when I click on it I see which resource failed against this control. I can also exclude findings that are approved by me because you know some manifest files have those configurations by design and some of them are being excluded for you in order to reduce all the noise. And the system not only shows you a bunch of failed resources. If you click on the fix button the platform will offer a remediation including specific information regarding what the issue is, where it is found and how you can fix it in order for you to fix it. I can also share the issue with my teammates. I can send that via Slack channel or I can even open a Jira ticket straight from here using the collaboration feature. And let's move to the vulnerability section. The platform scans for images that run inside the cluster and we can see vulnerabilities that were found. So we can filter or sort according to certain criteria like show me only the RCE vulnerabilities which are considered more likely a risky vulnerability or only the ones that have effects meaning I can do something about them or let's combine them both with the severity filter and this reduces the noise and filters everything that you know you need your attention to go to. From there I'll dive into one of the results, one of the scans and you see which vulnerability, which component, which version, how severe it is and which version I should upgrade this component to in order to fix this vulnerability. I can also use the exception if I don't want to be alert about it anymore and I can also look for a specific vulnerability in case I have that information and see where it is found in my images on my images in my cluster. The next section I want to talk about is the RBAC visualizer. It's considered by many to be one of the most complex things to manage in Kubernetes. So the platform offers an interactive visualizer to understand all your resources, your role bindings, your roles, cluster roles, who can access what, verbs, everything. We made it even easier to query using some built-in queries so you get useful information and important information and insights with no trouble. For example, show me all the cluster admins that I have in my cluster. And by the way, the C35 means that it's also misconfiguration covered as one of the controls. So we actually get context between the misconfiguration and the RBAC and this show how different section of the platform provides context when combined. And now I see all the cluster admins in my cluster. I can also have a reverse look and see which other roles this user is related to or which subjects are related to searching cluster roles depending on the need that I want. And I can go top down, I can go bottom up. Another example is show me all the unassigned roles, which is not a good practice to leave unassigned roles in your environment. And you can easily take action based on the information that you see here. I can also use the investigate tool where I can search for specific roles or users or services counts and so on and investigate from there. I can ask to see all the related resources or roles. And using the who can tool, I can further investigate and question and ask who can get or list for instance secrets in my environment. And you see there you go, it's actionable items. Everything we just played with is in the context of your clusters. But the platform also provides the same information regarding misconfiguration vulnerabilities outside the cluster. We can connect the ARML platform to different types of repository providers that you work with. This means that I can also scan for private or public repos before they are being pulled into my clusters. I can scan for image container registries before pulling them into my cluster. So this help prevents vulnerabilities from getting to my clusters and hardening my Kubernetes cluster. Back to the custom controls, there are many potential use cases for using chat GPT within the context of Kubernetes. Kubernetes can be challenging to navigate and fully utilize due to its complex nature and the need for a substantial understanding and set of skills. Any help that AI based tools like chat GPT can provide to make this test easier is welcomed. From writing a new Yano file to deploying a new cluster to securing it. In the case of the implementation I just showed you, we envision a custom framework made up of custom controls which will grow as you add controls to it. Our roadmap includes adding the ability to create custom frameworks that will host and save all the custom controls and enable the users to run them directly for ARML platform, thus making it easier for users to access and utilize their custom controls as well as streamline the process of adding new ones. This new type of custom framework will provide a more flexible and user friendly experience for our users. And in terms of upstream Cubescape, users will be able to contribute new controls to the Cubescape Paragl library and give back to the community that way. Once merged, these controls will be available for selection and use by all Cubescape and ARML platform users, thus making you part of our Cubescape community. And that's what I wanted to talk to you about today. I hope this has been informative for you and you know a little more about custom controls and ARML platform. I'll see you in the next webinar. Thank you for watching.