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.
- You want 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.
Note: To meet stringent isolation requirements, it is advisable to give priority to utilizing hardware-virtualized containers (e.g., Kata Containers) for compute isolation, in conjunction with network isolation provided by CNI's NetworkPolicy.
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.
vArmor reference documents are available at varmor.org.
⚙️ Installation
Thanks for your interest in contributing to vArmor! Here are some steps to help get you started:
🤝🏻 Read and agree to the code of conduct.
🛠️ Read the development guide.
💬 Join vArmor Lark group.
The vArmor project is licensed under Apache 2.0, except for third party components which are subject to different license terms. Please refer to the code header information in the code files.
Your integration of vArmor into your own projects should require compliance with the Apache 2.0 License, as well as the other licenses applicable to the third party components included within vArmor.
The eBPF code is located at vArmor-ebpf and licensed under GPL-2.0.
vArmor use cilium/ebpf to manage and interact with the eBPF program.
vArmor references part of the code of kyverno developed by Nirmata.
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)
vArmor has joined 404Starlink