Skip to main content
Version: main

Introduction

Learn about vArmor and create your first policy through a Quick Start guide.

About vArmor​

vArmor is a cloud-native container sandbox system. It leverages Linux's AppArmor LSM, BPF LSM and Seccomp technologies to implement enforcers. It can be used to strengthen container isolation, reduce the kernel attack surface, and increase the difficulty and cost of container escape or lateral movement attacks. You can leverage vArmor in the following scenarios to provide sandbox protection for containers within a Kubernetes cluster.

  • In multi-tenant environments, hardware-virtualized container solutions cannot be employed due to factors such as cost and technical conditions.
  • When there is a need to enhance the security of critical business containers, making it more difficult for attackers to escalate privileges, escape, or laterally move.
  • When high-risk vulnerabilities are present, but immediate remediation is not possible due to the difficulty or lengthy process of patching. vArmor can be used to mitigate the risks (depending on the vulnerability type or exploitation vector) to block or increase the difficulty of exploitation.
tip
  • The core of security defense lies in balancing risks and benefits, transforming uncontrollable risks into controllable costs by choosing different types of security boundaries and defense technologies.
  • runc + vArmor does not provide an isolation level equivalent to that of hardware virtualization containers (such as Kata Containers and other lightweight virtual machines). If you require a high-intensity isolation solution, please consider using hardware virtualization containers (such as Kata Containers) for compute isolation, and utilize CNI's NetworkPolicy for network isolation.

vArmor Features:

  • Cloud-Native. vArmor follows the Kubernetes Operator design pattern, allowing users to harden specific workloads by manipulating the CRD API. This approach enables sandboxing of containerized microservices from a perspective closely aligned with business needs.
  • Multiple Enforcers. vArmor abstracts AppArmor, BPF, and Seccomp as enforcers, supporting their use individually or in combination. This enables enforcing access control on container file access, process execution, network outbound, syscalls, and more.
  • Allow-by-Default. vArmor currently focuses on supporting this model, where only explicitly declared behaviors will be blocked, effectively minimizing performance impact and enhancing usability. It also supports auditing behaviors that violate the access control rules.
  • Built-in Rules. vArmor features a range of built-in rules ready to use out of the box. They are designed for the Allow-by-Default security model, eliminating the need for expertise in security profile creation.
  • Behavior Modeling. vArmor supports behavior modeling for workloads. This can be used for developing an allowlist profile, analyze which built-in rules can harden the application, or guide the configuration of workloads to adhere to the principle of least privilege.
  • Deny-by-Default. vArmor is capable of creating an allowlist profile from behavior models and ensuring that only explicitly declared behaviors are permitted.

vArmor was created by the Elkeid Team of the endpoint security department at ByteDance. And the project is still in active development.

How vArmor works​

Architecture​

vArmor primarily consists of two components: the Manager and the Agent. The Manager is responsible for responding to and managing policy objects, while the Agent handles the management of enforcers and profiles on Nodes.

Principle​

  • The VarmorPolicy and VarmorClusterPolicy CRs serve as user interfaces.
  • With VarmorPolicy or VarmorClusterPolicy objects, users can harden specific workloads and decide which enforcers and rules to use.
  • The ArmorProfile CR acts as an internal interface used for profile management.

When the Manager detects the creation event of a VarmorPolicy or VarmorClusterPolicy object, it generates a corresponding internal object called ArmorProfile. The Agent listens for and responds to this ArmorProfile object, processing the profiles and then reporting the status back to the Manager. When a user creates a workload, the APIServer sends the creation request to the Manager through the admission webhook. The Manager evaluates whether the workload should be hardened. If so, the Manager mutates the workload by adding annotations and modifying the securityContext. Finally, the workload's Pod will be scheduled to a Node, and the security context will be set when the container is created.

Key Terms​

The Enforcer​

vArmor abstracts AppArmor, BPF, and Seccomp as enforcers. The policy can use them individually or in combination to harden workloads, such as: AppArmorBPF, AppArmorSeccomp, AppArmorBPFSeccomp etc.

You can specify the enforcer through the spec.policy.enforcer field of VarmorPolicy or VarmorClusterPolicy objects.

The Policy Mode​

The vArmor policy can operate in five modes: AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling and DefenseInDepth. This flexibility allows it to meet the needs of different scenarios.

For more information, please refer to the Policy Modes.

The Built-in and Custom Rule​

When the policy is running in EnhanceProtect mode, Built-in Rules and Custom Rules can be used to harden the container. The policy operates with the Allow-by-Default security model, meaning only behaviors explicitly declared will be blocked. This approach minimizes performance impact while enhancing usability.

Prerequisites​

The prerequisites required by different enforcers are as shown in the following table.

EnforcerRequirementsRecommendations
AppArmor1. Linux Kernel 4.15 and above
2. The AppArmor LSM is enabled		GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
VKE with veLinux 1.0
Debian 10 and above
Ubuntu 18.04.0 LTS and above
veLinux 1.0 etc.
BPF1. Linux Kernel 5.10 and above (x86_64)
2. containerd v1.6.0 and above
3. The BPF LSM is enabled		EKS with Amazon Linux 2
GKE with Container-Optimized OS
VKE with veLinux 1.0 (with 5.10 kernel)
AKS with Ubuntu 22.04 LTS *
ACK with Alibaba Cloud Linux 3 *
OpenSUSE 15.4 *
Debian 11 *
Fedora 37
veLinux 1.0 with 5.10 kernel etc.

* Manual enabling of BPF LSM is required
Seccomp1. Kubernetes v1.19 and aboveAll Linux distributions

Quick Start​

Step 1. Fetch chart​

helm pull oci://elkeid-ap-southeast-1.cr.volces.com/varmor/varmor --version 0.5.11

Step 2. Install​

The default configuration enables the AppArmor and Seccomp enforcers. Please refer to the documentation for more configuration options.

helm install varmor varmor-0.5.11.tgz \
    --namespace varmor --create-namespace \
    --set image.registry="elkeid-ap-southeast-1.cr.volces.com"

You can use the domain elkeid-cn-beijing.cr.volces.com inside of the CN region.

Step 3. Try with this example​

Create demo namespace.

kubectl create namespace demo

Create a VarmorPolicy object to enable the AlwaysAllow mode for deployments that match the spec.target.selector.

cat << EOF | kubectl create -f -
apiVersion: crd.varmor.org/v1beta1
kind: VarmorPolicy
metadata:
  name: demo-1
  namespace: demo
spec:
  target:
    kind: Deployment
    selector:
      matchLabels:
        app: demo-1
  policy:
    enforcer: AppArmor
    mode: AlwaysAllow
EOF

View the status of VarmorPolicy & ArmorProfile object.

kubectl get VarmorPolicy -n demo
kubectl get ArmorProfile -n demo

Create the target Deployment object.

cat << EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-1
  namespace: demo
  labels:
    sandbox.varmor.org/enable: "true"
    app: demo-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-1
  template:
    metadata:
      labels:
        app: demo-1
      annotations:
        # Use this annotation to explicitly disable the protection for the container named c0.
        # It always takes precedence over the '.spec.target.containers' field.
        container.apparmor.security.beta.varmor.org/c0: unconfined
    spec:
      containers:
      - name: c0
        image: debian:10
        command: ["/bin/sh", "-c", "sleep infinity"]
        imagePullPolicy: IfNotPresent
      - name: c1
        image: debian:10
        command: ["/bin/sh", "-c", "sleep infinity"]
        imagePullPolicy: IfNotPresent

EOF

Retrieve the Pod name of the target Deployment object.

POD_NAME=$(kubectl get Pods -n demo -l app=demo-1 -o name)

Execute a command in container c1 to read the SA token.

kubectl exec -n demo $POD_NAME -c c1 -- cat /run/secrets/kubernetes.io/serviceaccount/token

Switch the VarmorPolicy object to EnhancedProtect mode to prohibit the container c1 from reading the secret token.

cat << EOF | kubectl apply -f -
apiVersion: crd.varmor.org/v1beta1
kind: VarmorPolicy
metadata:
  name: demo-1
  namespace: demo
spec:
  target:
    kind: Deployment
    selector:
      matchLabels:
        app: demo-1
  policy:
    enforcer: AppArmor
    mode: EnhanceProtect
    enhanceProtect:
      hardeningRules:
      - disable-cap-privileged
      attackProtectionRules:
      - rules:
        - mitigate-sa-leak
EOF

Execute a command in container c1 to read the SA token and verify that the reading behavior is prohibited.

kubectl exec -n demo $POD_NAME -c c1 -- cat /run/secrets/kubernetes.io/serviceaccount/token

Demo​

Below is a demonstration of using vArmor to harden a Deployment and defend against CVE-2021-22555 (The exploit is modified from cve-2021-22555).

For more demos, please check out our GitHub repository here.

image