 So cube armor, it's a long term protection for the Kubernetes and other cloud workloads. So it does provide an observability in policy enforcement system to restrict any unwanted or malicious behavior over the cloud native workloads at a long time. It was accepted by C&C, back in two years ago, at a sandbox maturity label. And recently, yeah, exactly a few weeks ago, they just submitted a proposal to more cube armor from the sandbox stage to the incubating stage. So exciting. Now that means in the past two years, cube armor has gained a lot of attractions from different organizations and the community. So let's say, what is cube armor? So in a shot, it's a runtime security enforcement tool. How it works. So you can see there is a diagram listed here. So cube armor is here, and it's running on different systems. So how it works, basically, first of all, it's leveraged the EVPF for the observability or monitoring to understand how your application behavior looks like, what processes you are using, what files you're using, what network ports you're using. And with the option discovery, you can better understand what the application behavior looks like from your runtime. And you can apply the zero-trust list of permissive control. And once you understand what's the situation from here and how to enforce the situation, let's say I just want to give three processes running, and I just need to access two files and maybe two network ports as well. So with the enforcement, it does leverage the ARCN. It's part of the Linux system modules to fully restrict the actions. So you can use it to do the secrets hardening, to do the inline remediation or prevention, and also to harden your applications. As you can see from the screen, not only support Kubernetes, it does support other containers and IoT devices or 5G networks. And so far, it has been downloaded over 700,000 times. It was created by Akinox, then donated to CNCF. So if I want to run CubeArmo, where I can run? So first of all, it can be running from all Kubernetes as a demo set, or it can be running from a virtual machine, any Linux virtual machine or physical machines. In ACK, it can also run from the Cuba mode. That's the new Kubernetes virtualization layer. So nowadays, people are moving away from the traditional virtual machine. They deploy many, many applications to the Kubernetes. Kubernetes is the standard platform. Now they just need a few VMs. You don't have to run a VM where hype will be on your tonics. So you literally, you can create the virtual machine from the Kubernetes cluster. That's Cuba mode. OK, so what's unique from a CubeArmo? So this is very important. So based on my understanding of the whole market right now, only CubeArmo does the inline intervention. You can leverage the zero trust. So how it works, I mentioned earlier, leverage the EVPF for the observability to identify the application behavior. I just needed three process. I only need to access two files. I only need to access two network ports. OK, so I understand the application behavior. I give these access, then I deny everything else. How to deny? It leveraged the LSE module. Could be my app or BPF or LSE or SE Linux. What are the vendors that do to prevent, you know, attack? What I described here is a post-attack mitigation. So vendor A, vendor B, vendor C, they are all using the EVPF. It's commonly used by all the network security vendor or it could be observability vendors. The main difference compared to CubeArmo, you can see, the vendor A, yes. It's a very good tool to detect various malicious activities. Someone is taking over, might do something, attack to your system. So vendor A detects the problems, then kill the processor from the user space. So here is the problems. From the time you detect the problems until you kill the process, there is a gap. So maybe somebody already took your secrets, already copied your service account, or maybe somebody already started to encrypt your systems. Rensho already started to encrypt your system. Even just 20 milliseconds, it's happening. It's already happening. So it becomes the problem, it's too late. So whatever vendor B and vendor C, they take different approach. They detect the problems, then they kill the processor from the code of space, and then at the end of the day, they stop the containers. So the main, still, again, the difference compared to CubeArmo, it's too late. You detect the problems, you kill the processor, you stop the containers. Some already took the secrets, some already encrypted your system. It's too late. So that's why CubeArmo becomes very popular, especially for the government, fire engine industries. Some of the companies require heavily zero trust architecture. So for the runtime. Okay, so I'm a Kubernetes guy. I love Kubernetes. So let's say, how CubeArmo, what system are supported? So first of all, we talk about a Kubernetes, it can be running as a demo sets, or it can be running from other containerized applications. In this case, it will be running as a system demoed, or it can be running from any virtual machine, a bare metal machines, but right now only support Linux. So on the right-hand side, you can see what Kubernetes is supporting. Votions, all the main Kubernetes, including GKE, AKS, OK, IBM, AKS, EKS, et cetera, even OpenShift, MicroShift, RKE, et cetera. So all different Kubernetes Linux distributions also supported, you've got a SUSE here, Ubuntu here, Red Hat here, Amazon Linux, et cetera. Okay? So again, I'm a Kubernetes guy. I want to show you how it looks like from the Kubernetes environment. So this is an architect. So I've got a Kubernetes cluster here. I've got multiple pods running here. CubeArmo running here as a demo sets from the user space. And from here, it will leverage the EVP for the monitoring or observability to understand what resources you're using. And then how to apply the enforcement. So again, I want to highlight, leverage the LSMs. And by creating the security policy, basically it's a demo file, and then apply it to the system, by the ACY Linux or BPF LSM, apply to the system, and then block the, you know, only allow the good guys to pass, block the hacker activities. But also, CubeArmo also provided the command line tool for you to verify to do the in-sport to observe or what's happening to provide you the recommendation based on the different compliance framework, could be like a CIS, NIST, STIGs, et cetera. So once they detect any problems, it will send you the alerts. So it can be the standard output or can be sent to the external SIM tools. So how it works for the external SIM tool, let's see. So it does, CubeArmo does allow you to extend the outputs with the CubeArmo Relay server. So by default, the CubeArmo Relay server will be deployed with CubeArmo. It will be running on every note. And with the CubeArmo Relay server here, it allow you to collect all the messages, alerts or system logs from each node and then allow other logging systems to collect these through the service. So here's a diagram to show you how you can stream CubeArmo telemetry to other SIM tools. So as you can see from the diagram, so we are using Azure Sentinel as an example. You're gonna communicate across the running here. You're gonna CubeArmo running from all different nodes and it can be configured by the CubeArmo Relay. You can set the standard output to Azure Sentinel, for example. What type of telemetry event supporting? So it could be a lot when the policy is violating or it could be a log when a policy executes a Cisco or any other actions, such as a fire access, a processor creation, could be network, socket creators, connector, acceptor, et cetera. Or could be any messages, the internal CubeArmo demo messages. So how to stream to the SIM tool? There are two ways. One is to admire the CubeArmo Relay thing out. The other way is to admire the adapter. You can create an adapter here, allow you to talk to CubeArmo Relay server and then collect the messages and send the message to Azure Sentinel, or could be Splunk, or could be Brokano, or any other SIM tools. So excited. This is a very cool tool to secure your runtime across all different environment Kubernetes, your Linux runtime, your virtual machine, your physical machines. Let's see a live demo. So I realized it took a little bit of time. So I decided to record a separate video to show you how to install CubeArmo to the Kubernetes cluster, how to run a few test cases to show you how to broker certain processes, how to broker fire access. It could be you just want to audit someone is trying to access your secrets, for example. So that's all for today. Thank you for watching. I hope it is useful to you. If you find it useful, please do share and like it. Thank you so much. Have a good day.