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 MoreSecurity Policy Deployment in multiUbuntu with KubeArmor
KubeArmor, a container-aware runtime security enforcement system
Read MoreSecuring your Kubernetes Cluster Defense in Depth with Kyverno
With the recent pace of innovation in cloud and cloud-native adoption
Read MoreSample 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
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
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
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
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