簡介

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 的應用場景

01、多租戶隔離

多租戶應用的風險

現代 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 層面進行入侵檢測和防御，及時發現并響應入侵行為。

02、核心業務加固

加固的收益

雖然業內已經推出了一些基于硬件虛擬化技術和用戶態內核的強隔離方案（例如 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 豐富的特性為安全策略的制定和運營提供了多樣的選擇，以下是一些常見的使用方式：

• 僅告警不攔截模式（觀察模式）：將沙箱策略配置為僅告警不攔截模式，通過采集告警日志來分析安全策略對目標應用的影響。

spec:
  policy:
    enforcer: BPF
    mode: EnhanceProtect
    enhanceProtect:
      # 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.
      # It's disabled by default.
      auditViolations: true
      # AllowViolations determines whether to allow the actions that are against the mandatory access control rules.
      # It's disabled by default.
      allowViolations: true

• 攔截并告警模式：沙箱策略制定完成后，可調整為攔截并告警模式運行，并持續采集告警日志。從而實現對目標工作負載的強制訪問控制，并及時發現違規行為。
  xxxxxxxxxx

   

  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
• 高危漏洞應對：當出現高危漏洞時，您可以基于漏洞類型或利用向量分析對應的緩解方案，并通過更新策略對象（添加內置規則、自定義規則），在漏洞修復前進行防御。

spec:
  policy:
    enforcer: BPF
    mode: EnhanceProtect
    enhanceProtect:
      # The custom AppArmor rules:
      appArmorRawRules:
      - rules: |
          audit deny /etc/hosts r,
          audit deny /etc/shadow r,
      - rules: "audit deny /etc/hostname r,"
        targets:
        - "/bin/bash"
      # The custom BPF LSM rules:
      bpfRawRules:
        processes:
        - pattern: "**ping"
          permissions:
          - exec
        network:
          egresses:
          - ip: fdbd:dc01:ff:307:9329:268d:3a27:2ca7
          - ipBlock: 192.168.1.1/24
            port: 80
          sockets:
          - protocols:
            - "udp"
      # The custom Seccomp rules:
      syscallRawRules:
      - names:
        - fchmodat
        action: SCMP_ACT_ERRNO
        args:
        - index: 2
          value: 0x40     # S_IXUSR
          valueTwo: 0x40
          op: SCMP_CMP_MASKED_EQ
        - index: 2
          value: 0x8      # S_IXGRP
          valueTwo: 0x8
          op: SCMP_CMP_MASKED_EQ
        - index: 2
          value: 1        # S_IXOTH
          valueTwo: 1
          op: SCMP_CMP_MASKED_EQ

• 策略影響排查：當用戶懷疑沙箱策略影響目標應用正常執行時，可將策略模式動態切換為 AlwaysAllow、RuntimeDefault 模式排查（注：已啟動容器的 Seccomp Profile 不支持動態更新）。

kubectl patch vcpol $POLICY_NAME --type='json' -p='[{"op": "replace", "path": "/spec/policy/mode", "value":"AlwaysAllow"}]'

• 行為建模模式：使用實驗功能 —— 行為建模模式，對目標應用進行建模。建模完成后使用策略顧問來生成沙箱策略模版，輔助沙箱策略的制定。

spec:
  policy:
    enforcer: AppArmorSeccomp
    mode: BehaviorModeling
    modelingOptions:
      # The duration in minutes to modeling
      duration: 30

03、特權容器加固

特權容器的定義

特權容器通常指包含 .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 文件的寫權限。

# mount a new procfs
mkdir /tmp/proc
mount -t proc tmpproc /tmp/proc
echo "xxx" > /tmp/proc/sys/kernel/core_pattern




# bind mount a procfs
mount --bind /proc/sys /tmp/proc
mount -o remount,rw /tmp/proc /tmp/proc
echo "xxx" > /tmp/proc/sys/kernel/core_pattern

使用 vArmor 的內置規則disallow-mount-procfs可阻斷此利用向量。

policy:
  enforcer: BPF
  mode: EnhanceProtect
  enhanceProtect:
    hardeningRules:
    - disallow-mount-procfs
    # Privileged is used to identify whether the policy is for the privileged container.
    # Default is false.
    privileged: true

輔助特權容器降權

企業生產環境中往往存在許多“特權容器”，雖然大量研究報告和案例都闡明過使用“特權容器”的危害，但企業可能仍然難以對已有的“特權容器”進行降權，也無法按照最小權限原則授予新增容器必要的 capabilities。

vArmor 提供了實驗功能 —— 行為建模模式。用戶可以創建此模式的安全策略，并在指定時間范圍內收集和處理目標工作負載的行為。建模結束后，vArmor 會生成一個 ArmorProfileModel 對象，用來保存目標工作負載的行為模型。當行為數據較多時，行為數據會被緩存在數據卷中，用戶可以通過對應接口將其導出。

spec:
  policy:
    enforcer: AppArmorSeccomp
    # Switching the mode from BehaviorModeling to others is prohibited, and vice versa.
    # You need recraete the policy to switch the mode from BehaviorModeling to DefenseInDepth.
    mode: BehaviorModeling
    modelingOptions:
      # The duration in minutes to modeling
      duration: 30

行為數據包括目標應用所需的 capability、執行的進程、讀寫的文件、調用的 syscall 等，用戶可以利用這些信息來輔助降權。請參考使用說明(https://www.varmor.org/zh-cn/docs/main/guides/policies_and_rules/policy_modes/behavior_modeling/#%E4%BD%BF%E7%94%A8%E8%AF%B4%E6%98%8E)進一步了解如何使用 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 服務。其輕量化設計具備四大優勢：

1. 原生級性能損耗：依托內核安全子系統，不顯著增加上下文切換和數據拷貝開銷
2. 無需額外硬件：純軟件實現
3. 無環境綁定：不依賴特定操作系統
4. 零侵入性：保持集群及容器運行時組件的默認配置

總結

vArmor 針對當前容器安全領域在安全策略編寫與管理方面的難題，提供了有效的解決方案。在多租戶隔離場景下，盡管無法達到硬件虛擬化容器的隔離級別，但通過配合一系列安全實踐，可降低跨租戶攻擊風險；在核心業務加固方面，vArmor 憑借云原生、靈活、開箱即用和易用等特性，為企業在享受 runc 容器性能與便捷的同時，提供了有效的安全防護手段；對于特權容器，vArmor 既能通過內置和自定義規則加固，阻斷常見攻擊手法，又能利用行為建模功能輔助降權。

vArmor 以其豐富的特性和靈活的應用方式，為容器安全提供了全面且實用的保障，助力企業在云原生環境中平衡安全與業務發展的需求。真誠歡迎社區開發者和企業加入社區，與我們一起參與項目共建。

引用

1. PEACH: A Tenant Isolation Framework for Cloud Applications
   原文鏈接：https://www.datocms-assets.com/75231/1671033753-peach_whitepaper_ver1-1.pdf
2. Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms
   原文鏈接：https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms
3. Pod Security Standards
   原文鏈接：https://kubernetes.io/docs/concepts/security/pod-security-standards/
4. 2024 Data Breach Investigations Report
   原文鏈接：https://www.verizon.com/business/resources/Te3/reports/2024-dbir-data-breach-investigations-report.pdf
5. #BrokenSesame: Accidental ‘write’ permissions to private registry allowed potential RCE to Alibaba Cloud Database Services
   原文鏈接：https://www.wiz.io/blog/brokensesame-accidental-write-permissions-to-private-registry-allowed-potential-r

相關鏈接

項目地址：https://github.com/bytedance/vArmor

項目官網：https://varmor.org