KubeArmor: eBPF-Based Runtime Security Enforcement

Introduction

In mid-2021, KubeArmor emerged as a novel approach to runtime security enforcement for Kubernetes, using eBPF (extended Berkeley Packet Filter) to monitor and filter system calls at the kernel level. Unlike Falco’s detection-focused approach, KubeArmor provided enforcement capabilities that could block unauthorized actions before they occurred.

This mattered because runtime security had become a critical layer in defense-in-depth strategies. While admission controllers (Gatekeeper, Kyverno) prevented bad configurations from being deployed, runtime security tools like KubeArmor prevented bad behavior from occurring inside running containers. KubeArmor’s eBPF-based approach provided low-overhead enforcement that was practical for production deployments.

Historical note: KubeArmor was developed by Accuknox and gained attention in 2021 for its eBPF-based enforcement approach. It would reach GA in 2022, establishing itself as a key runtime security tool alongside Falco.

KubeArmor Architecture

eBPF-Based Enforcement

• Kernel-Level Monitoring: Uses eBPF to monitor system calls at the kernel level.
• Low Overhead: eBPF provides efficient system call filtering with minimal performance impact.
• Real-Time Enforcement: Blocks unauthorized actions in real-time before they execute.
• Container Awareness: Understands Kubernetes context (pods, namespaces, labels).

Policy Model

• Kubernetes CRDs: Policies defined as Kubernetes Custom Resources.
• Label-Based Selection: Policies applied based on pod labels and namespaces.
• Process, File, Network Controls: Fine-grained control over system operations.
• Capability Restrictions: Restrict Linux capabilities and system calls.

KubeArmor vs Falco vs AppArmor/SELinux

Policy Examples

Process Execution Control

apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-shell-execution
  namespace: production
spec:
  selector:
    matchLabels:
      app: web
  process:
    matchPaths:
    - path: /bin/sh
      action: Block
    - path: /bin/bash
      action: Block
    - path: /usr/bin/sh
      action: Block

File Access Control

apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: protect-sensitive-files
  namespace: production
spec:
  selector:
    matchLabels:
      app: database
  file:
    matchPaths:
    - path: /etc/passwd
      action: Block
      readOnly: true
    - path: /etc/shadow
      action: Block

Network Access Control

apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: restrict-network-access
  namespace: production
spec:
  selector:
    matchLabels:
      app: web
  network:
    matchProtocols:
    - protocol: TCP
      fromSource:
      - matchLabels:
          app: frontend
      toPorts:
      - port: 8080
    action: Allow
  network:
    action: Block

Comparison: KubeArmor vs Falco

Choose KubeArmor When:

• Enforcement Required: Need to block unauthorized actions, not just detect them.
• Zero Trust: Implementing zero-trust security model with default deny.
• Compliance: Need to enforce security policies for compliance requirements.
• Performance Critical: Need low-overhead enforcement for high-performance workloads.

Choose Falco When:

• Detection Focus: Need threat detection and alerting, not enforcement.
• Forensic Analysis: Need detailed logs for security incident investigation.
• Flexible Rules: Need complex detection rules for anomaly detection.
• Alerting Integration: Need integration with SIEM and alerting systems.

Practical Considerations

Performance Impact

KubeArmor’s eBPF-based enforcement has minimal performance impact:

• CPU Overhead: Typically < 2% CPU per node.
• Memory Usage: ~50-100MB per KubeArmor instance.
• Latency: System call filtering adds < 1ms latency.

Policy Management

• Policy Testing: Test policies in non-production environments first.
• Gradual Rollout: Enable policies gradually, starting with audit mode.
• Policy Complexity: Complex policies can impact performance; optimize carefully.
• Documentation: Document why each policy exists and what it protects.

Integration with Kubernetes

• RBAC: Use RBAC to control who can create KubeArmor policies.
• Namespace Isolation: Policies are namespace-scoped; plan policy distribution.
• Label Management: Policies depend on pod labels; maintain label consistency.

Getting Started

# Install KubeArmor
kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/deployments/kubearmor.yaml

# Create a policy
cat <<EOF | kubectl apply -f -
apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-shell-execution
  namespace: default
spec:
  selector:
    matchLabels:
      app: web
  process:
    matchPaths:
    - path: /bin/sh
      action: Block
EOF

# Verify policy
kubectl get kubearmorpolicies

Caveats & Lessons Learned

• Policy Testing: Policies can block legitimate operations; test thoroughly.
• False Positives: Some policies may block legitimate workloads; tune policies.
• Performance: Complex policies can impact performance; monitor and optimize.
• Kubernetes Version: Some features require specific Kubernetes versions.

Common Failure Modes

• “Workloads blocked”: Policies block legitimate operations; review and adjust policies.
• “Performance degradation”: Too many policies slow down system calls; optimize policies.
• “Policy not enforced”: Policies not matching pods; check label selectors.

Conclusion

KubeArmor’s introduction in 2021 marked a significant advancement in Kubernetes runtime security enforcement. It provided teams with the ability to enforce security policies at the kernel level, blocking unauthorized actions before they could cause harm. While Falco focused on detection, KubeArmor focused on enforcement, enabling zero-trust security models.

For organizations implementing zero-trust security, KubeArmor became an essential runtime security tool. It demonstrated that runtime security didn’t have to be detection-only—it could be enforcement-focused, blocking threats in real-time. KubeArmor proved that eBPF-based security could be both powerful and performant, enabling teams to secure their clusters at the kernel level without sacrificing performance.

The patterns and practices established with KubeArmor would influence the development of advanced runtime security tools and set the foundation for comprehensive runtime security in Kubernetes. KubeArmor demonstrated that Kubernetes security could be enforced at multiple layers: admission (Gatekeeper, Kyverno), network (NetworkPolicy), and runtime (KubeArmor, Falco).