Protecting Your Kubernetes Environment With KubeArmor

KubeArmor, as Falco, is a Cloud Native Computing Foundation (CNCF) Sandbox project, representing an early-stage endeavor poised to potentially develop into a crucial element within the cloud-native ecosystem.

KubeArmor’s primary goal is to enforce security for containers running on Kubernetes.

It aims to achieve this by leveraging the underlying Linux security modules, such as AppArmor and Seccomp.

When I first looked into KubeArmor, I wondered how it differs from AppArmor.

Although they share similarities, such as the capacity to restrict access to particular processes or files, KubeArmor offers an additional layer of protection customized for securing containers within Kubernetes environments.

Additionally, it uses the universally recognized YAML syntax for policy definitions, whereas AppArmor employs its own profile syntax.

While KubeArmor leverages Linux security modules like AppArmor to enforce policies, it goes beyond by utilizing more advanced features, such as seccomp and auditd, for a more comprehensive approach to container security.

Another difference is that KubeArmor operates at the Kubernetes cluster level, seamlessly integrating with its ecosystem. At the same time, AppArmor functions at the host level, focusing on individual applications running on a Linux system.

Installing KubeArmor

I installed KubeArmor on a Kubernetes KubeAdm cluster running on Google Cloud, which I use for training and evaluation.

To simplify installation, KubeArmor provides a command-line interface (CLI). To install the CLI, run the following command:

curl -sfL http://get.kubearmor.io/ | sudo sh -s -- -b /usr/local/bin

Upon successful download and installation, you can proceed to install KubeArmor using the following method:

karmor install

Successfully Installing KubeArmor on a Kubernetes cluster

KubeArmor uses a deamonset to install pods on every node of your cluster in the kube-system namespace.

The pods installed by de KubeArmor installation in the kube-system namespace

Create a pod with a security vulnerability

To demonstrate KubeArmor’s capabilities, I will return to the ShellShock scenario. We will deploy a pod hosting a web server with a CGI application vulnerable to the ShellShock exploit.

The deployment below sets up the web server and the susceptible CGI application. Install it by executing the command kubectl create -f shellshock.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: shellshock
  name: shellshock
spec:
  replicas: 1
  selector:
    matchLabels:
      app: shellshock
  template:
    metadata:
      labels:
        app: shellshock
    spec:
      containers:
      - image: vulnerables/cve-2014-6271
        name: cve-2014-6271

When the pod is running, we can access it using curl via a temporary pod. We run the following command.

kubectl run mycurlpod --image=curlimages/curl -i --tty -- sh

Executing this command initiates a pod containing an image with curl and immediately launches a shell. Upon curling the ShellShock pod, the following output is displayed.

Curl the default index.html page of the http webserver

The displayed HTML page indicates that the container image is vulnerable to ShellShock.

Now, let’s attempt to exploit the ShellShock vulnerability by executing the following command within the curlpod.

curl -H "user-agent: () { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'" \
http://192.168.1.6/cgi-bin/vulnerable

The resulting output demonstrates that we successfully exploited the vulnerability by crafting a unique user-agent string, which led to the execution of a command that revealed the contents of the /etc/passwdfile.

Exploiting the ShellShock vulnerability by sending a special HTTP header

The ShellShock exploit was a vulnerability found in the bash shell. Given that CGI bin applications utilize bash to expand key values in headers, the exploit could be triggered by incorporating an unusual header value, such as { :; }.

Creating and connecting the KubeArmor policy

Our goal is to create a KubeArmor policy and link it with the vulnerable pod, guaranteeing that even though the vulnerability exists, exploitation is prevented.

First, we must develop an AppArmor policy that prevents the execution of bash by the CGI application.

Developing an AppArmor policy is a relatively simple procedure. We begin by utilizing a selector to identify the pod or deployment to which the policy applies.

Subsequently, we use the process key to specify that access to /bin/bash must be restricted. Refer to the policy below for more details.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-shellshock
  namespace: default
spec:
  selector:
    matchLabels:
      app: shellshock
  process:
    matchPaths:
      - path: /bin/bash
  action:
    Block

We install the policy using kubectl create -f kubearmor-shellshock-policy.yaml

Retrying to exploit the ShellShock vulnerability

Now that the KubeArmor profile has been established, we can test the ShellShock vulnerability again and observe the results.

To do so, we will recreate the curlpod and execute the curl command with the exploit in the header field. Please refer to the screenshot below for reference.

Initially, we will attempt to curl the webserver for index.html, which should function normally.

Following this, we will attempt the exploit, which should no longer work due to KubeArmor’s blocking of bash execution.

The exploit does not work anymore, as the KubeArmor policy is in effect

Nothing happens after we try to exploit ShellShock via the curl command. We could not list the contents of the /etc/passwd file.

If we look at the logs of apache in the ShellShock pod, we see that the access to /bin/bash was denied.

The webservers log shows that the executing of bash was denied

This demonstrates that although the vulnerability still exists within the pod, KubeArmor’s implementation successfully prevents exploitation, thereby ensuring the system’s security.

Conclusion

KubeArmor represents a valuable tool for safeguarding containerized environments within Kubernetes.

Although this article only provided a brief overview of the capabilities of KubeArmor, it demonstrated the tool’s effectiveness in preventing the exploitation of a known ShellShock vulnerability within a pod of our cluster.

This highlights the value of KubeArmor as a proactive security measure capable of identifying and blocking potential threats before they can cause damage.

By leveraging underlying Linux security modules such as AppArmor, KubeArmor provides a comprehensive approach to enforcing security policies, preventing unauthorized access, and stopping potential threats.

Moreover, KubeArmor’s flexible policy framework and support for YAML syntax enable easy customization and management of security policies.

With its active development and growing community support, KubeArmor is poised to become a vital component of the cloud-native ecosystem.