Context

Today we will turn our attention towards securing your pods deployed on Kubernetes. Although there are many aspects to ensure that your pod is secured but in this blog we will explain how you can protect some specific files and folders in your container. What do I mean by protecting is that you want to block the access to that file or folder. This blog is not about How to do this but about How KubeArmor does that! If you want to get started with KubeArmor please visit their website, it's very beginner friendly, you just need to install Helm Operator to get started. Once you have applied a KubeArmor policy you can continue to this blog.

Components of KubeArmor

If you will visit website of KubeArmor, you will see this as an introduction:

KubeArmor is a runtime Kubernetes security engine. It uses eBPF and Linux Security Modules(LSM) for fortifying workloads based on Cloud Containers, IoT/Edge, and 5G networks. It enforces policy-based controls.

When I first read this, I was able to understand only first line! I am expecting same with you. Let's dive into the second line! What is eBPF and LSM?

eBPF

You might have heard the recent CrowdStrike issue, and you probably also know the root cause of it! It's because Windows Kernel allows third-party drivers to change the source code of it! And now you know how much problematic it can be! This is what eBPF does safely. It extends the capabilities of Linux Kernel without changing the source code of it! Now you would wonder why even we require that? Honestly speaking there are so many uses of it, it can be used for Performance Monitoring, Security (by monitoring system calls and network traffic) and networking. Mostly eBPF is used for for observance to enhance security. This blog is not about eBPF and LSM, we will try to get the required context and then move to the main topic and I think this much knowledge of eBPF is enough, we should know dive into LSM!

LSM

LSM (Linux Security Modules) is a framework within the Linux kernel that allows various security policies to be enforced on the system. Now you would be able to understand it's need in KubeArmor! What KubeArmor does on high-level, LSM does it at low-level. You can't always write templates for LSMs and therefore you use KubeArmor which provides you a much safer way to implement security policies easily and efficiently. There are many types of LSMs but KubeArmor majorly supports for three:

BPF-LSM
AppArmor LSM
SE-LINUX Enforcer

We will study about these in coming sections but before that we should study firstly try to get the overall context of KubeArmor!

Overall Structure

This is more for Kubernetes environment but KubeArmor also supports un-orchestrated environments. But in this blog we will see it's k8s side more. So if you want to install KA on k8s, you would do that by installing operator on your cluster. Now What is operator? It's the packaging process of Kubernetes components to ease the installation of new external components! So, KA operator doesn't protect your pod/container rather it pulls KA daemon and that part is responsible to secure your cluster or node or pod. Another part of operator is the controller, What is controller? As the name is saying it is used to control the state of kubearmor. Kubernetes doesn't know anything about KA, so how it will ensure that desired state related to KubeArmor is always up? You guessed it right! The installed controller will do that. This was a high level structure of KubeArmor Operator but it's not the end of this blog! We will now dive into the heart of KubeArmor that is KubeArmor Daemon.

KubeArmor Daemon

As stated above, this is the core of KubeArmor that means it will be responsible for securing your components. It starts with identifying all the details related to your node and the environment (whether it is Kubernetes or not!) For simplicity we will assume that environment is k8s. Once all the details related to nodes is fetched and confirmation for a healthy cluster is done it move forwards. It currently supports three CRIs: Docker, Crio-O and ContainerD. Directly from node, it identifies the CRI (if environment is not k8s then it uses CRI socket to identify) and updates itself with the CRI. Now it will start monitoring the system events (that's what is related to secure the processes and files in your container), once the monitor is initialized it will initialize the Runtime Enforcer! What is it? At the lowest level, it is that component of KubeArmor which identifies and use the supported LSMs to enable security. If you will go inside the code of Runtime Enforcer, you will understand that how beautifully KA is automatically securing your pod. Take an example of Apparmor Enforcer of KA, This is how the app armor profiles look like:

#include <tunables/global>

/usr/bin/myapp {
    #include <abstractions/base>

    # Capabilities
    capability net_bind_service,
    capability setuid,
    capability setgid,

    # Network access
    network inet stream,
    network inet dgram,

    # File read/write access
    /etc/myapp/** r,
    /var/log/myapp/** rw,
    /var/lib/myapp/** rw,
    /tmp/** rw,

    # Deny access to /etc/shadow
    deny /etc/shadow rw,

    # Disallow ptrace
    deny ptrace,

    # Allow execution
    /usr/bin/myapp rix,
}

This is what KA does for you, at the core it will implement these profiles in your app armor and restricts the access to files/directories. Similar things will happen with other LSMs. KubeArmor will ease the job of security as now you don't need to make a separate security team to monitor these files and interact with LSMs to ensure security and honestly if your team will try to do this, they will end up with the same software as KubeAmor, so why not KubeArmor! It is doing for you at free of cost!

Not just that once the enforcement is completed it will continue to monitor your containers and alert you on any breach! This was just one of the parts of KubeArmor. Obviously I can't explain every part of it! But let's try to get an overview of the flow of kubearmor! See this:-

So if we see at the very core, KubeArmor is a great tool to automate the security of your pod/node/cluster. It gives an option to apply the security policies in a very layman yaml language. You need not to know about ebpf and LSMs to ensure security and that's where the beauty of KA lies!

Conclusion

This blog was not an absolute beginner friendly but for the beginners who are learning Kubernetes. If you will try to contribute to any of the CNCF project, you will observe that it is extending the Kubernetes and exposing an operator. I have been reading the codebase of KubeArmor for the last two weeks and I am little confident now that I can now write my own operator, Thanks to KubeArmor!!! If you are the one who was searching about contributing to KubeArmor, I hope that this blog has helped you. Although this blog explains a very small part of KubeArmor and that too from a very high level but I think it will provide you a starting point to understand KubeArmor.

Internals of KubeArmor: Security in Containers