Runtime protection for Kubernetes & other cloud Workloads

KubeArmor uses eBPF and Linux Security Modules (LSM) to provide policy based system
to restrict any unwanted, malicious behavior of cloud-native workloads at runtime.

How to install KubeArmor

Key Features

Restrict the behavior of containers and other workloads

KubeArmor provides the ability to restrict specific behavior of process executions, file accesses, networking operations, and resource utilization inside of your workload. level.

Enforce security policies at runtime

KubeArmor directly enforces security policies using Linux Security Modules (LSMs) for each workload based on the identities (e.g., labels) of given containers or workloads.

Generate logs when policy violations occur

KubeArmor produces alert logs for policy violations by monitoring the operations of containers' processes using its eBPF-based monitor.

Provide effortless semantics for policy definitions

KubeArmor manages internal complexities associated with LSMs and provides easy semantics for policy definitions.

Support network security enforcement among containers

KubeArmor allows applying policy settings at the level of network system calls, controlling interactions among containers.

Provide Kubernetes-native security enforcement engine

KubeArmor allows operators to define security policies based on Kubernetes metadata and simply apply them into Kubernetes.

Blogs

Announcing KubeArmor Support for EKS-Anywhere

This blog goes over the steps to deploy KubeArmor on EKS Anywhere

Read More
Security Policy Deployment in multiUbuntu with KubeArmor

KubeArmor, a container-aware runtime security enforcement system

Read More
Securing your Kubernetes Cluster Defense in Depth with Kyverno

With the recent pace of innovation in cloud and cloud-native adoption

Read More

Sample Policies


      apiVersion: security.accuknox.com/v1
      kind: KubeArmorPolicy
      metadata:
        name: ksp-wordpress-config-block
        namespace: wordpress-mysql
      spec:
        severity: 10
        selector:
          matchLabels:
            app: wordpress
        file:
          matchPaths:
          - path: /var/www/html/wp-config.php
            fromSource:
            - path: /usr/sbin/apache2
            action: Allow
          - path: /var/www/html/wp-config.php
            action: Block
      
Copy Icon


    apiVersion: security.accuknox.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: ksp-mysql-dir-audit
      namespace: wordpress-mysql
    spec:
      severity: 5
      selector:
        matchLabels:
          app: mysql
      file:
        matchDirectories:
        - dir: /var/lib/mysql/
          recursive: true
      action: Audit
    
Copy Icon

      apiVersion: security.accuknox.com/v1
      kind: KubeArmorPolicy
      metadata:
        name: ksp-wordpress-process-block
        namespace: wordpress-mysql
      spec:
        severity: 3
        selector:
          matchLabels:
            app: wordpress
        process:
          matchPaths:
          - path: /usr/bin/apt
          - path: /usr/bin/apt-get
        action: Block
      
Copy Icon


    apiVersion: security.accuknox.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: ksp-wordpress-sa-block
      namespace: wordpress-mysql
    spec:
      severity: 8    
      tags: ["MITRE"]    
      message: "block the k8s credential access"    
      selector:    
        matchLabels:    
          app: wordpress
      file:
        matchDirectories:           
        - dir : /run/secrets/kubernetes.io/serviceaccount/           
          recursive: true
      action: Block
    
Copy Icon

Use Cases

Description

K8s mounts the service account token as part of every pod by default. The service account token is a credential that can be used as bearer token to access k8s APIs and gain access to other k8s entities. Many a times there are no processes in the pod that use service account token which means in such cases the k8s service account token is an unused asset that can be leveraged by the attacker.

Attack Scenario

An attacker would check for credential accesses so as to do lateral movements. For e.g., in most k8s attacks, the attacker after gaining entry into the k8s pods tries to use service account token and gain access into other entities.

Sample Policy


apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-wordpress-block-sa
  namespace: wordpress-mysql
spec:
  severity: 7
  selector:
    matchLabels:
      app: wordpress
  file:
    matchDirectories:
      - dir: /run/secrets/kubernetes.io/serviceaccount/
        recursive: true
        # cat /run/secrets/kubernetes.io/serviceaccount/token
        # curl https://$KUBERNETES_PORT_443_TCP_ADDR/api --insecure --header "Authorization: Bearer $(cat /run/secrets/kubernetes.io/serviceaccount/token)"
  action: Block
    

Description

Changes to system binary folders, configuration paths, credentials paths needs to be monitored for change. With KubeArmor, one can not only monitor for changes but also block any write attempts in such system folders. Compliance frameworks such as PCI-DSS, SOX, NERC CIP, FISMA, HIPAA, SANS expect FIM to be in place.

Attack Scenario

An attacker might want to update the configuration so as to disable security controls or access logs.

Sample Policy


apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: fim-for-system-paths
  namespace: dvwa
spec:
  action: Block
  file:
    matchDirectories:
      - dir: /bin/
        readOnly: true
        recursive: true
      - dir: /sbin/
        readOnly: true
        recursive: true
      - dir: /usr/sbin/
        readOnly: true
        recursive: true
      - dir: /usr/bin/
        readOnly: true
        recursive: true
  message: Alert! An attempt to write to system directories denied.
  severity: 5
  tags:
    - NIST
    - PCI-DSS
    

Description

Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to adversary controlled web servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. Installation of a root certificate on a compromised system would give an adversary a way to degrade the security of that system.

Attack Scenario

Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.

Sample Policy


apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: protect-trust-bundles
  namespace: dvwa
spec:
  action: Block
  file:
    matchDirectories:
      - dir: /etc/ssl/
        readOnly: true
        recursive: true
      - dir: /etc/pki/
        readOnly: true
        recursive: true
      - dir: /usr/local/share/ca-certificates/
        readOnly: true
        recursive: true
  message: Credentials modification denied
  severity: 1
  tags:
    - MITRE
    - MITRE_T1552_unsecured_credentials
    

Description

You can use a security feature called "process isolation" or "process whitelisting" to set specific processes to be executed as part of a container or pod, and deny everything else. This can help to secure a containerized environment by limiting the processes that can run within it, and preventing unauthorized processes from being executed.

Attack Scenario

Attacker uses command injection techniques to insert binaries in the pods/workloads and then execute the binary. Process-Whitelisting will deny any unknown process from execution.

Sample Policy


apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: allow-specific-process
  namespace: dvwa
spec:
  action: Allow
  file:
    matchDirectories:
      - dir: /
        recursive: true
  process:
    matchPaths:
      - path: /bin/bash
      - fromSource:
          - path: /bin/dash
        path: /bin/ping
      - fromSource:
          - path: /usr/sbin/apache2
        path: /bin/sh
      - path: /usr/sbin/apache2
  selector:
    matchLabels:
      app: dvwa-web
      tier: frontend
  severity: 1
    

Description

Pods/Containers might get shipped with binaries which should never used in the production environments. Some of those bins might be useful in dev/staging environments but the same container image is carried forward in most cases to the production environment too. For security reasons, the devsecops team might want to disable use of these binaries in the production env even though the bins exists in the container. As an example, most of the container images are shipped with package management tools such as apk, apt, yum, etc. If anyone ends up using these bins in the prod env, it will increase the attack surface of the container/pod.

Attack Scenario

Attackers use system tools such fsck, ip, who, apt etc for reconnaissance and to download its accessory tooling from the remote servers.

Sample Policy

This policy denies execution of package management tools such as apt, apt-get in the target pods.


apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-wordpress-block-process
  namespace: wordpress-mysql
spec:
  severity: 3
  selector:
    matchLabels:
      app: wordpress
  process:
    matchPaths:
      - path: /usr/bin/apt
      - path: /usr/bin/apt-get
  action: Block
    

KubeArmor is licensed under the Apache License, Version 2.0.
The eBPF-based container monitor is licensed under the General Public License, Version 2.0.


© 2023 The KubeArmor Authors All Rights Reserved

KubeArmor was created by the team at

© 2023 The Linux Foundation. All Rights Reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of the Linux Foundation, please see our Trademarks Usage page.