 Hello, everyone, I'm Shubham Duttamasi. I'm currently working as a dev well at Akinox, and today we are discussing about how we can secure our Kubernetes environment with QVarner. A little bit of background. I'm a certified Kubernetes administrator and a security specialist, and in my career I've worked in the different areas such as 5G, cloud, private data centers, air gap networks, DevOps, and blockchains. So when we talk about cloud-native runtime security, there are so many areas we have to cover. For example, how our clusters are set up, how if there is a vendor, let's say a public cloud vendor, how they are securing our environment. If let's say we have some edge location deployments, for example, in 5G, how those edge locations are secured. So there are a lot of areas in terms of security that we have to cover. Now let's talk about static procedure mission-oriented runtime security. When we are building our image, tool such as TV can help us detect the area of any vulnerabilities in our container image. At the time of applying that image to our Kubernetes cluster, tools such as OPA, Kyberno can help us if, for example, our image, our container image is coming from the current registry. And when we talk about runtime security, that is a Kubernetes network policy for a network policy built-in. We have Falco and specifically we have Q-Barmor for helping us secure our entire environment. So what does runtime security entitles? So when we are running our application, we have to see security on all the areas where our application is going through. For example, network, if it's our network secure, if we have let's say deployed MTLS, is our MTLS working fine? Is it applied on our application? If our application is accessing some files, some processes, are those secure enough? If we are application is writing some data, is those endpoints are secure? Can, do we know if those things are not malicious? We understand that in terms of security is hard. We understand that the application that we were running on the staging environment cannot, as this we put in the production environment because due to security reasons. And most of the time, we don't even have security control in our hands. If let's say we are moving towards cloud vendors, such as EKS or GKE. So we have existing runtime security solutions, but those security solution mostly give us alerts, but they do not enforce anything. If let's say an attacker is trying to attack us, attack will happen. You will just get the note that we were attacked. Now let's talk about QBARMA. QBARMA can not only detect that an attack is happening, but it can prevent any attack from happening in the first place using any security modules. So approach matters. If we are doing post-exploitation mitigation, that is not of the right way to do it. If let's say an attack happened and we got an alert, the attack has happened. After that, we are killing the process. By the time we might have lost all our data, right? So this is a thing which we want to prevent. So let's talk about how other applications are currently doing it, and how QBARMA is doing things differently. So for the observability, all of us use EBBF, so we can detect things at the kernel level. But what QBARMA does is we can, using BPF LSM, we can enforce an attack from ever happening in the first place. Now let's talk about inline mitigation or supposed to take mitigation. When an attack is happening, using LSMs, QBARMA can stop the attack from ever happening in the first place. But when we talk about post attack, the harm is already done. Kubernetes also provides us for security context for security in our existing application. We can apply some native policies such as SC Linux or app armor, but all those policies are not consistent with all different flavors of Kubernetes. Plus we don't get any alerts because there is no LSM support. So basically no BPF LSM support we don't get out of the box. So that's what QBARMA can help us using the LSMs. Using simple YAML definition, we can control our policies. It can be SC Linux, it can be BPF LSM, it can be app armor. But as an end user, you don't have to worry about how QBARMA is securing your environment internally. We understand that writing these policies are hard. That's why QBARMA give you template policies for applying in your application which can do audit or enforcement. When it comes to network segmentation, QBARMA's discovery engine can also provide you native Kubernetes network policy which we can be applied over at CNI level. So using BPF LSM, we can secure our application at the time of runtime. And the plus part is that it is by default available on all Linux kernel. So your QBARMA application will work fine in any environment. Here are some demo policy. If let's say we want to audit our some directory, if we want to block some binaries for executing some files, if let's say we want no one should be able to read our security tokens, or if we want to block package management solutions, just APT. Now let's talk about the use case. Many companies choose Hashi Cloud Board as their solution for securing all the secrets in their environment. And by default, there is a binary called vault which is at the location of slash bin slash vault which access all the data at the vault directory at data path and configuration path. And however else we're attacking happen that if an attacker gets access to our vault container, they can encrypt all our data and ask us for some ransom. How QBARMA can help us that we allow only that, only the authorized binaries should be able to access the vault's data. Even if any attacker gets inside our container, they will not be able to see anything. So this is a sample vault policy which can be applied in a Kubernetes cluster. So only the authorized binaries are allowed to read and write the data from the vault directory. And this is available with all major cloud vendors. So defining policies are hard. You have CVCM network policies, Kubernetes network policies, QBARMA policies. We need an automated mechanism for generating all these policies. So when you deploy QBARMA, our discovery engine will automatically detect the actions that are happening. Let's say if some process is running some binary, if some process is executing some file, if some process is executing by some network. So our discovery engine will tell us how which policy should be applied. And we support all the latest deployments of Kubernetes, even if you're running the things in the containerize, even if you're running things on virtual machine level or a bare-middle level, we support x86 and arms both platforms. Now let's jump into a demo. We can start by installing a K-ARMA CLI tool. This is used for controlling our QBARMA environment. So as we can see, our K-ARMA CLI tool has been installed. Let's see if QBARMA is running inside our cluster or not. As we can see, the QBARMA is not running. Let's install it. Now QBARMA is up and running. So K-ARMA Pro will tell us how our QBARMA is securing our environment through activation. We have AC Linux, we have APARMA, and PPVLSM. Currently, our environment is secured via PPVLSM. Now let's try to install an application. We have deployed a simple engine export. Let's also expose our network. Okay, now our pod is up and running. Our service is also up. Let's see if we are getting any data back. Okay, now our website is up. Now, K-ARMA profile will give us insight sort of how our application is handling all the processes. We can see, okay, what processes are executed, which files are executed. If they are in network calls, there are only six calls. Let's talk about file. Now, doing all the things on my cluster, let me run the call command again. As you see, when I run the call command, I notice that there is a process called engineX, which uses this file. And as you can see, the count is one. If I run it again, now count has moved to two. And when we come to the network calls, we see, okay, similar behavior. So, Q-ARMA, even without applying any policies, Q-ARMA is detecting how our application is behaving internally. Now, using Q-ARMA probe, it tells us that in the default namespace, we have a pod called engineX, but there are no policies applied. Let's see how an attacker can attack our application. An attacker can get inside our pod, hack our file. And now as we do the call again, so we got hacked. But how do we prevent that? Let's try to do something different. Let's first reset our pod. We can apply, so what we have done is, we have applied a simple Q-ARMA policy that will help us protect our environment. Only the engineX binary is allowed to execute this file. Nothing else. Now let's do the call again. We see our website is running. Let's run the probe. We see, okay, now there is a policy applied. What we can now do is try to hack our application again. We can get inside the container and let's try to hack our application again. As you can see, the permission was denied. So if only engineX is trying to access our application, the engineX binary is trying to access our data, is only allowed to read this content, otherwise no other file is able to do anything with our content. If we, now let's talk about some of the advanced topics. Using K-ARMA recommend can give us all the policy templates which can be applied on our cluster. So here are the all the policies which are generated by Q-ARMA. Take an example of this. EngineX latest package management execution. Let's try to apply this policy and test our application again. So these are our policies which are just generated by Q-ARMA. Let's, okay. Now I'm again in my engineX container. Let me try to do APT update. As an attacker, when I'm inside a cluster, I can go inside and I can break things. I can download malicious software for hacking your environment. Now as in a MIDI, let's apply the package policy. So what this package policy is doing is actually helping us prevent from anything. Let's read its content. So as you can see, it's blocking all the APT and all those things. Now as we have applied the policy, let's try to run APT update again. As you can see, the permission was denied. So even if I'm inside the container and policy is applied, I will not be able to do anything. Q-ARMA somebody can give us detailed view of what's happening inside our cluster. For example, which methods are we using? So this will give you like all the processes which are allowed by the kernel level, by the process level. And we can use this data for applying better policies to our system. And as if we want to clean up our environment, we can just do Q-ARMA administrator. This will delete Q-ARMA if needed. Thank you. Thank you. If you have any questions, feel free to reach out at asti.acunox.com.