vArmor 是字节跳动开源的云原生容器沙箱系统，它借助 Linux 的
AppArmor LSM，BPF LSM
和
Seccomp
技术进行容器加固。用户可以通过 vArmor 的 CRD API 在 Kubernetes 集群中管理安全策略，对指定工作负载的容器进行加固。vArmor 旨在降低利用现有技术加固容器的门槛和成本，从而平衡安全风险与防护成本。
本文将介绍我们推出 vArmor 项目的目的，然后从技术角度出发介绍其在不同场景的应用。本文将向您展示如何凭借vArmor 的技术特性来解决特定问题，从而实现技术与业务目标，助力企业构建云原生环境下的安全防线。
容器运行时组件和 Kubernetes 早已增加了对 LSM、Seccomp 的支持，其中 Seccomp 在 Kubernetes v1.19 GA，AppArmor LSM 在 Kubernetes v1.30 GA。用户可以自行编写和管理 AppArmor、SELinux、Seccomp Profiles，并在工作负载中配置安全策略对其进行加固。几乎所有的容器运行时组件都附带了默认的 AppArmor 和 Seccomp 安全策略，但默认的 Seccomp 策略需要显式设置才会为容器开启，而默认的 AppArmor 策略需要操作系统支持才会为容器自动开启。
充分利用 Linux 系统的安全机制可以有效加固容器。例如通过 LSM、Seccomp 等技术对容器进程进行强制访问控制，可以减少内核攻击面、增加容器逃逸或横向移动攻击的难度与成本。它们的基本原理如下图所示。
-
容器运行时组件的默认安全策略存在局限性，无法防御某些漏洞、错误配置风险，也不能限制攻击者在容器内的渗透行为。
-
构建 AppArmor、Seccomp、SELinux Profile 需要专业知识。
-
为复杂且快速迭代的容器化应用制定健壮的安全策略（尤其是 Deny-by-Default 模式的策略）难度较大。
-
AppArmor 或 SELinux LSM 依赖操作系统发行版，存在一定局限性。
-
在 Kubernetes 环境中，自动化管理和应用不同的安全策略比较复杂。
为了解决这些问题，vArmor 应运而生。它提供了多种策略模式、内置规则和配置选项，vArmor 会根据策略对象的定义，管理安全策略（AppArmor Profile、BPF Profile、Seccomp Profile）对不同工作负载的容器进行加固。vArmor 还基于 BPF 和 Audit 技术实现了行为建模功能，可以对不同应用进行行为采集并生成行为模型，从而辅助构建安全策略。
例如，用户可以按需配置策略对象，实现违规拦截、拦截并告警、只告警不拦截三种效果，并
使用内置规则和自定义规则动态更新策略对象，从而满足不同应用场景的需要。下面我们将用几个实际应用场景来展示 vArmor 如何助力企业提升云原生环境中的容器安全防护能力。
现代 SaaS 应用程序大多采用多租户模式，严重的漏洞及相应的利用链，极有可能致使恶意用户得以访问其他租户的数据。随着大语言模型时代来临，云服务的使用量还会进一步增长。因此，构建此类服务的人员更需关注多租户隔离风险并采取防范举措，以降低跨租户攻击的风险。
下图是 Wiz 在 PEACH 框架中描绘的一个典型跨租户攻击序列 [1]：
大量案例表明，跨租户漏洞、漏洞利用链的根因主要包括：
-
用户接口复杂度较高，接口中的无害 bugs、features 加剧风险
-
-
Wiz 在 PEACH 框架中指出，针对多租户应用，应根据安全建模结果，综合合规、数据敏感度、成本等因素选择租户隔离技术方案。企业可以通过选择不同类型的安全边界和防御技术，将不可控风险转化为可控成本。
租户隔离用于弥补由于接口的复杂性而带来的多租户隔离安全风险。而接口复杂度则与漏洞出现概率正相关，下表描述了接口复杂度的简单评估方法 [1]。
因此，对于复杂接口（如支持租户执行任意代码的组件），建议选择高隔离等级的安全边界来保障租户数据安全，例如基于轻量级虚拟机技术的容器。
对于不复杂的租户场景和接口，如文件解析、数据解析、网页渲染、文件上传等，可考虑使用 vArmor 等技术方案进行加固。
由于 runc + vArmor 的隔离等级不及硬件虚拟化容器（如 Kata Container 等轻量级虚拟机容器），因而无法防御所有容器逃逸漏洞。因此，在使用 vArmor 加固多租户应用时，需假设高级攻击者可能会利用漏洞逃逸到宿主机。我们建议您配合以下安全实践，来增加攻击者逃逸后进一步攻击的难度和成本，并及时发现攻击行为。
-
租户负载应满足 Pod Security Standard 的 Baseline 或 Restricted 标准 [2]，并使用 NetworkPolicy 等技术实施网络微隔离。
-
制定合理的调度策略，避免不同租户负载调度到同一个节点。
-
不同租户使用独占命名空间，以最小权限原则授予租户负载有限的 Kubernetes RBAC 和 IAM 权限，避免授予敏感权限。敏感 RBAC 权限列表可参考 Palo Alto Networks 发布的白皮书 [3]。
-
制定合理的调度策略，将具有敏感 Kubernetes RBAC 和 IAM 权限的系统组件负载调度到专用节点池，确保租户负载所在节点不存在可被滥用的服务账号和用户账号。
-
系统组件的敏感接口应开启身份认证和鉴权，避免未授权漏洞。
-
引入入侵检测系统，在主机、Kubernetes 层面进行入侵检测和防御，及时发现并响应入侵行为。
虽然业内已经推出了一些基于硬件虚拟化技术和用户态内核的强隔离方案（例如 Kata、gVisor 等），但由于其技术门槛和成本较高，使得 runc 容器仍将是大部分业务场景的主流。用户在享受 runc 容器带来的性能与便捷时，也面临着诸如容器隔离性较弱的安全问题。例如近年来 Linux 内核、runc 组件、容器运行时组件的漏洞频发，每隔一段时间就会有新的漏洞可被用于容器逃逸等攻击；许多企业在容器化应用设计、开发、部署时，也易因错误设计和配置引入逃逸风险。
Verizon 发布的研究报告 [4] 表明，企业在补丁可用后平均需 55 天才能解决 50% 的关键漏洞，而影响基础设施的漏洞修复时间可能更长。当某个高危漏洞被全量修复后，可能又有新的漏洞出现并等待修复。在漏洞修复期间，企业往往缺乏除了入侵检测以外的防御措施。
vArmor 的以下特性，使其成为加固核心业务的选择：
-
云原生：遵循 Kubernetes Operator 设计模式，贴近云原生应用开发和运维习惯，从业务视角加固容器化应用，因此易于理解和上手。
-
灵活性：策略支持多种运行模式（例如 AlwaysAllow、RuntimeDefault、EnhanceProtect 模式），可动态切换且无需重启工作负载。支持拦截、拦截并告警、仅告警不拦截三种特性，有助于策略调试和安全监控。
-
开箱即用：基于字节跳动在容器安全领域的攻防实践，提供了一系列内置规则，用户可按需在策略对象中选择使用。vArmor 会根据策略对象的配置，生成和管理 Allow-by-Default 模式的 AppArmor、BPF、Seccomp Profile，降低了对专业知识的要求。
-
易用性：提供了行为建模功能、策略顾问工具，从而辅助策略制定，进一步降低了使用门槛。
vArmor 丰富的特性为安全策略的制定和运营提供了多样的选择，以下是一些常见的使用方式：
-
仅告警不拦截模式（观察模式）：将沙箱策略配置为仅告警不拦截模式，通过采集告警日志来分析安全策略对目标应用的影响。
spec: policy: enforcer: BPF mode: EnhanceProtect enhanceProtect: auditViolations: true allowViolations: true
拦截并告警模式：沙箱策略制定完成后，可调整为拦截并告警模式运行，并持续采集告警日志。从而实现对目标工作负载的强制访问控制，并及时发现违规行为。
spec: policy: enforcer: BPF mode: EnhanceProtect enhanceProtect: auditViolations: true
高危漏洞应对：当出现高危漏洞时，您可以基于漏洞类型或利用向量分析对应的缓解方案，并通过更新策略对象（添加内置规则、自定义规则），在漏洞修复前进行防御。
spec: policy: enforcer: BPF mode: EnhanceProtect enhanceProtect: appArmorRawRules: - rules: | audit deny /etc/hosts r, audit deny /etc/shadow r, - rules: "audit deny /etc/hostname r," targets: - "/bin/bash" bpfRawRules: processes: - pattern: "**ping" permissions: - exec network: egresses: -
