Protecting Your Kubernetes Environment With KubeArmor

In a previous article on Kubernetes security, I discussed using AppArmor to enhance the security of container processes by limiting their actions and resource access.

As a result, we successfully thwarted a hacker’s attempt to exploit the ShellShock vulnerability present in one of our containers.

Last week, I received a message from Nat Natraj, the CEO of AccuKnox. He read my article on Falco and wanted to introduce me to KubeArmor, an open-source solution developed by his company.

During the past week, I explored KubeArmor to evaluate its potential for enhancing security.

What is 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

KubeArmor uses a deamonset to install pods on every node of your cluster 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.

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/passwd file.

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.

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.

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.