vArmor：云原生容器安全的多场景应用实践

简介

vArmor 是字节跳动开源的云原生容器沙箱系统，它借助 Linux 的 AppArmor LSM，BPF LSM 和 Seccomp 技术进行容器加固。用户可以通过 vArmor 的 CRD API 在 Kubernetes 集群中管理安全计谋，对指定工作负载的容器进行加固。vArmor 旨在降低使用现有技术加固容器的门槛和本钱，从而平衡安全风险与防护本钱。
本文将介绍我们推出 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 如何助力企业提拔云原生环境中的容器安全防护本事。
vArmor 的应用场景

多租户隔离

多租户应用的风险

现代 SaaS 应用程序大多接纳多租户模式，严峻的漏洞及相应的使用链，极有大概致使恶意用户得以访问其他租户的数据。随着大语言模子期间来临，云服务的使用量还会进一步增长。因此，构建此类服务的人员更需关注多租户隔离风险并接纳防范举措，以降低跨租户攻击的风险。
下图是 Wiz 在 PEACH 框架中刻画的一个典型跨租户攻击序列 [1]：

大量案例表明，跨租户漏洞、漏洞使用链的根因主要包罗：

• 用户接口复杂度较高，接口中的无害 bugs、features 加剧风险
  
• 多租户共享组件实现不妥。
  
• 多租户独占组件安全边界实现不妥。
  

针对这些题目，可接纳以下缓解措施：

• 淘汰用户接口复杂度
  
• 将共享组件变化成租户独占组件
  
• 提拔租户独占组件的隔离性
  

如何选择加固方案

Wiz 在 PEACH 框架中指出，针对多租户应用，应根据安全建模效果，综合合规、数据敏感度、本钱等因素选择租户隔离技术方案。企业可以通过选择不同范例的安全边界和防御技术，将不可控风险转化为可控本钱。
租户隔离用于弥补由于接口的复杂性而带来的多租户隔离安全风险。而接口复杂度则与漏洞出现概率正相关，下表描述了接口复杂度的简单评估方法 [1]。

Interface type	Typical input (example)	Typical process	Complexity level
Arbitrary code execution environment	Arbitrary	Execution	High
Database client	SQL query	Database operation	High
Arbitrary file scanner	Arbitrary	Parsing	Medium
Binary data parsing	Protobuf	Parsing	Medium
Web crawler	JavaScript	Rendering	Medium
Port scanner	Metadata	Parsing	Low
Reverse proxy	Arbitrary	Proxy	Low
Queue message upload	Arbitrary	Proxy	Low
Data entry form	String	Parsing	Low
Bucket file upload	Arbitrary	Storage	Low

因此，对于复杂接口（如支持租户实行任意代码的组件），建议选择高隔离等级的安全边界来保障租户数据安全，比方基于轻量级虚拟机技术的容器。对于不复杂的租户场景和接口，如文件解析、数据解析、网页渲染、文件上传等，可考虑使用 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 的理由

vArmor 的以下特性，使其成为加固核心业务的选择：

• 云原生：遵照 Kubernetes Operator 设计模式，贴近云原生应用开发和运维风俗，从业务视角加固容器化应用，因此易于明白和上手。
  
• 灵活性：计谋支持多种运行模式（比方 AlwaysAllow、RuntimeDefault、EnhanceProtect 模式），可动态切换且无需重启工作负载。支持拦截、拦截并告警、仅告警不拦截三种特性，有助于计谋调试和安全监控。
  
• 开箱即用：基于字节跳动在容器安全范畴的攻防实践，提供了一系列内置规则，用户可按需在计谋对象中选择使用。vArmor 会根据计谋对象的设置，生成和管理 Allow-by-Default 模式的 AppArmor、BPF、Seccomp Profile，降低了对专业知识的要求。
  
• 易用性：提供了行为建模功能、计谋顾问工具，从而辅助计谋制定，进一步降低了使用门槛。
  

常见用法

vArmor 丰富的特性为安全计谋的制定和运营提供了多样的选择，以下是一些常见的使用方式：

• 仅告警不拦截模式（观察模式）：将沙箱计谋设置为仅告警不拦截模式，通过收罗告警日志来分析安全计谋对目标应用的影响。
  
  1. spec:
  2.   policy:
  3.     enforcer: BPF
  4.     mode: EnhanceProtect
  5.     enhanceProtect:
  6.       # AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Any detected violation will be logged to /var/log/varmor/violations.log file in the host.
  7.       # It's disabled by default.
  8.       auditViolations: true
  9.       # AllowViolations determines whether to allow the actions that are against the mandatory access control rules.
  10.       # It's disabled by default.
  11.       allowViolations: true

  复制代码
  
  
• 拦截并告警模式：沙箱计谋制定完成后，可调解为拦截并告警模式运行，并持续收罗告警日志。从而实现对目标工作负载的欺压访问控制，并实时发现违规行为。
  
  1. spec:
  2.   policy:
  3.     enforcer: BPF
  4.     mode: EnhanceProtect
  5.     enhanceProtect:
  6.       # AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Any detected violation will be logged to /var/log/varmor/violations.log file in the host.
  7.       # It's disabled by default.
  8.       auditViolations: true

  复制代码
  
  
• 高危漏洞应对：当出现高危漏洞时，您可以基于漏洞范例或使用向量分析对应的缓解方案，并通过更新计谋对象（添加内置规则、自定义规则），在漏洞修复前进行防御。
  
  1. spec:
  2.   policy:
  3.     enforcer: BPF
  4.     mode: EnhanceProtect
  5.     enhanceProtect:
  6.       # The custom AppArmor rules:
  7.       appArmorRawRules:
  8.       - rules: |
  9.           audit deny /etc/hosts r,
  10.           audit deny /etc/shadow r,
  11.       - rules: "audit deny /etc/hostname r,"
  12.         targets:
  13.         - "/bin/bash"
  14.       # The custom BPF LSM rules:
  15.       bpfRawRules:
  16.         processes:
  17.         - pattern: "**ping"
  18.           permissions:
  19.           - exec
  20.         network:
  21.           egresses:
  22.           - ip: fdbd:dc01:ff:307:9329:268d:3a27:2ca7
  23.           - ipBlock: 192.168.1.1/24
  24.             port: 80
  25.           sockets:
  26.           - protocols:
  27.             - "udp"
  28.       # The custom Seccomp rules:
  29.       syscallRawRules:
  30.       - names:
  31.         - fchmodat
  32.         action: SCMP_ACT_ERRNO
  33.         args:
  34.         - index: 2
  35.           value: 0x40     # S_IXUSR
  36.           valueTwo: 0x40
  37.           op: SCMP_CMP_MASKED_EQ
  38.         - index: 2
  39.           value: 0x8      # S_IXGRP
  40.           valueTwo: 0x8
  41.           op: SCMP_CMP_MASKED_EQ
  42.         - index: 2
  43.           value: 1        # S_IXOTH
  44.           valueTwo: 1
  45.           op: SCMP_CMP_MASKED_EQ

  复制代码
  
  

• 计谋影响排查：当用户猜疑沙箱计谋影响目标应用正常实行时，可将计谋模式动态切换为 AlwaysAllow、RuntimeDefault 模式排查（注：已启动容器的 Seccomp Profile 不支持动态更新）。
  
  1. kubectl patch vcpol $POLICY_NAME --type='json' -p='[{"op": "replace", "path": "/spec/policy/mode", "value":"AlwaysAllow"}]'

  复制代码
  
  

• 行为建模模式：使用实验功能 —— 行为建模模式，对目标应用进行建模。建模完成后使用计谋顾问来生成沙箱计谋模版，辅助沙箱计谋的制定。
  
  1. spec:
  2.   policy:
  3.     enforcer: AppArmorSeccomp
  4.     mode: BehaviorModeling
  5.     modelingOptions:
  6.       # The duration in minutes to modeling
  7.       duration: 30

  复制代码
  
  

特权容器加固

特权容器的定义

特权容器通常指包含 .securityContext.privileged=true 设置的容器，此类容器被授予全部 capabilities，可访问宿主机全部装备和内核接口。本文将全部拥有打破隔离性设置的容器称为 “特权容器”，包罗但不限于 privileged container、sensitive capabilities、sensitive mounts、shared namespaces、sensitive RBAC permissions。
许多企业因历史遗留题目、系统设计需求、安全意识不敷等原因，在生产环境的业务负载和系统组件中引入了 “特权容器”。然而，这些容器的风险设置容易被攻击者使用，从而导致容器逃逸、横向移动等攻击。比方在 Wiz 披露的 BrokenSesame [5] 漏洞使用链中，容器间共享 PID ns、管理容用具有特权等风险设计和错误设置，就可被攻击者使用进行横向移动和权限提拔攻击。

降低特权容器的风险

我们建议企业优先以最小权限原则评估并移除导致 “特权容器” 的风险设置。并在无法移除时，使用强隔离级别的安全边界来加固容器。
vArmor 可以作为增补，在彻底消除 “特权容器” 的安全风险条件供一定的加固本事。用户可使用 vArmor 提供的内置规则和自定义规则来限定潜在攻击者的行为，阻断已知的攻击手法，提拔攻击本钱和入侵检测几率。vArmor 内置了 “容器加固”、“攻击防护” 和 “漏洞缓解” 三类规则，并且还在不绝更新。在 “容器加固” 类规则中，vArmor 专门为 “特权容器” 安全风险内置了一系列规则，可用于阻断一些已知的攻击手法。
比方，在拥有 CAP_SYS_ADMIN capability 的容器中，通过改写宿主机的 core_pattern 来逃逸容器是常见的攻击手法。如下所示，攻击者可以通过挂载新的 procfs、重新挂载 procfs、移动 procfs 挂载点等方式获取宿主机 core_pattern 文件的写权限。

1. # mount a new procfs
2. mkdir /tmp/proc
3. mount -t proc tmpproc /tmp/proc
4. echo "xxx" > /tmp/proc/sys/kernel/core_pattern
7. # bind mount a procfs
8. mount --bind /proc/sys /tmp/proc
9. mount -o remount,rw /tmp/proc /tmp/proc
10. echo "xxx" > /tmp/proc/sys/kernel/core_pattern

复制代码

使用 vArmor 的内置规则disallow-mount-procfs可阻断此使用向量。

1. policy:
2.   enforcer: BPF
3.   mode: EnhanceProtect
4.   enhanceProtect:
5.     hardeningRules:
6.     - disallow-mount-procfs
7.     # Privileged is used to identify whether the policy is for the privileged container.
8.     # Default is false.
9.     privileged: true

复制代码

辅助特权容器降权

企业生产环境中往往存在许多“特权容器”，虽然大量研究报告和案例都阐明过使用“特权容器”的危害，但企业大概仍然难以对已有的“特权容器”进行降权，也无法按照最小权限原则授予新增容器必要的 capabilities。
vArmor 提供了实验功能 —— 行为建模模式。用户可以创建此模式的安全计谋，并在指定时间范围内收集和处理目标工作负载的行为。建模结束后，vArmor 会生成一个 ArmorProfileModel 对象，用来生存目标工作负载的行为模子。当行为数据较多时，行为数据会被缓存在数据卷中，用户可以通过对应接口将其导出。

2. spec:
3.   policy:
4.     enforcer: AppArmorSeccomp
5.     # Switching the mode from BehaviorModeling to others is prohibited, and vice versa.
6.     # You need recraete the policy to switch the mode from BehaviorModeling to DefenseInDepth.
7.     mode: BehaviorModeling
8.     modelingOptions:
9.       # The duration in minutes to modeling
10.       duration: 30

复制代码

行为数据包罗目标应用所需的 capability、实行的进程、读写的文件、调用的 syscall 等，用户可以使用这些信息来辅助降权。请参考使用阐明进一步相识如何使用 vArmor 的行为建模功能。注：当前仅 AppArmor 和 Seccomp enforcer 支持行为建模功能。

兼容性阐明

vArmor 依托 Linux 系统的安全机制（AppArmor LSM、BPF LSM、Seccomp）来实现容器加固，其中

• AppArmor enforcer 需系统启用 AppArmor LSM
  
• BPF enforcer 需 Linux 5.10+ 内核版本支持
  

目前 vArmor 兼容 Kubernetes v1.19+ 版本，支持包罗 AWS EKS、Azure AKS、Google GKE、火山引擎 VKE、阿里云 ACK 等主流云厂商的托管 Kubernetes 服务。其轻量化设计具备四大优势：

• 原生级性能损耗：依托内核安全子系统，不显著增加上下文切换和数据拷贝开销
  
• 无需额外硬件：纯软件实现
  
• 无环境绑定：不依赖特定操作系统发行版
  
• 零侵入性：保持集群及容器运行时组件的默认设置
  

总结

vArmor 针对当前容器安全范畴在安全计谋编写与管理方面的难题，提供了有用的办理方案。在多租户隔离场景下，尽管无法到达硬件虚拟化容器的隔离级别，但通过配合一系列安全实践，可降低跨租户攻击风险；在核心业务加固方面，vArmor 依附云原生、灵活、开箱即用和易用等特性，为企业在享受 runc 容器性能与便捷的同时，提供了有用的安全防护手段；对于特权容器，vArmor 既能通过内置和自定义规则加固，阻断常见攻击手法，又能使用行为建模功能辅助降权。
vArmor 以其丰富的特性和灵活的应用方式，为容器安全提供了全面且实用的保障，助力企业在云原生环境中平衡安全与业务发展的需求。朴拙欢迎社区开发者和企业加入社区，与我们一起到场项目共建。

引用

• PEACH: A Tenant Isolation Framework for Cloud Applications
  
• Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms
  
• Pod Security Standards
  
• 2024 Data Breach Investigations Report
  
• #BrokenSesame: Accidental ‘write’ permissions to private registry allowed potential RCE to Alibaba Cloud Database Services
  
  
  
   
  相关链接
  
  项目地址：
  https://github.com/bytedance/vArmor
  项目官网：https://varmor.org
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。