跳到主要内容
版本：main

简介

了解 vArmor 并通过快速入门指南创建您的第一个策略。

关于 vArmor​

vArmor 是一个云原生容器沙箱系统，它借助 Linux 的 AppArmor LSM, BPF LSM 和 Seccomp 技术实现强制访问控制器（即 enforcer），从而对容器进行安全加固。它可以用于增强容器隔离性、减少内核攻击面、增加容器逃逸或横行移动攻击的难度与成本。

您可以借助 vArmor 在以下场景对 Kubernetes 集群中的容器进行沙箱防护

  • 业务场景存在多租户（多租户共享同一个集群），由于成本、技术条件等原因无法使用硬件虚拟化容器。
  • 想要对关键的业务进行安全加固，增加攻击者权限提升、容器逃逸、横向渗透的难度与成本。
  • 当出现高危漏洞，但由于修复难度大、周期长等原因无法立即修复时，可以借助 vArmor 实施漏洞利用缓解（具体取决于漏洞类型或漏洞利用向量。缓解代表阻断利用向量、增加利用难度）。
提示
  • 安全防御的核心在于平衡风险与收益，通过选择不同类型的安全边界和防御技术，将不可控风险转化为可控成本。
  • runc + vArmor 不提供等同硬件虚拟化容器（如 Kata Container 等轻量级虚拟机）的隔离等级。如果您需要高强度的隔离方案，请优先考虑使用硬件虚拟化容器（如 Kata Container）进行计算隔离，并借助 CNI 的 NetworkPolicy 进行网络隔离。

vArmor 的特点

  • Cloud-Native. vArmor 遵循 Kubernetes Operator 设计模式，用户可通过操作 CRD API 对特定的 Workloads 进行加固。从而以更贴近业务的视角，实现对容器化微服务的沙箱加固。
  • Multiple Enforcers. vArmor 将 AppArmor、BPF、Seccomp 抽象为 Enforcer，并支持单独或组合使用，从而对容器的文件访问、进程执行、网络外联、系统调用等进行访问控制。
  • Allow-by-Default. vArmor 当前重点支持此安全模型，即只有显式声明的行为会被阻断，从而减少性能损失和增加易用性。vArmor 还支持对违反访问控制规则的行为进行审计。
  • Built-in Rules. vArmor 提供了一系列开箱即用的内置规则。这些规则为 Allow-by-Default 安全模型设计，从而极大降低对用户专业知识的要求。
  • Behavior Modeling. vArmor 支持对工作负载进行行为建模。这可用于开发白名单安全策略、分析哪些内置规则可用于加固应用、指导工作负载的配置遵循权限最小化原则。
  • Deny-by-Default. vArmor 可以基于行为模型创建白名单安全策略，从而确保仅显式声明的行为被允许。

vArmor 项目由字节跳动终端安全团队的 Elkeid Team 创建，目前该项目仍在积极迭代中。

vArmor 如何工作​

架构​

vArmor 主要由 Manager 和 Agent 两个组件构成。Manager 用于响应和管理安全策略，而 Agent 则在集群节点上管理 enforcer（强制访问控制器）和 profile（安全配置文件）。

原理​

  • VarmorPolicy 和 VarmorClusterPolicy CR 是 vArmor 的用户接口。
  • 您可以通过管理 VarmorPolicy 或 VarmorClusterPolicy CR 策略对象，使用不同的强制访问控制器及其规则来加固容器。
  • ArmorProfile CR 作为内部接口，用于安全配置文件的管理。

当 Manager 监听到 VarmorPolicy 或 VarmorClusterPolicy 对象的创建事件时，它会为其创建一个对应的 ArmorProfile 内部对象。Agent 监听并响应这个 ArmorProfile 对象，处理安全配置文件后将状态报告回 Manager。当用户创建工作负载时，APIServer 通过准入 webhook 将创建请求发送到 Manager。Manager 评估是否应该加固工作负载。如果需要，Manager 通过添加注释和修改 securityContext 等来变异工作负载。最后，工作负载的 Pod 将被调度到节点上，并在创建容器时为其设置安全上下文。

关键术语​

强制访问控制器​

vArmor 将 AppArmor, BPF, Seccomp 抽象为强制访问控制器（即 enforcer）。安全策略可以单独、组合使用它们来加固工作负载，例如：BPF、AppArmorBPF、AppArmorSeccomp、AppArmorBPFSeccomp 等。

您可以在 VarmorPolicy 或 VarmorClusterPolicy 对象的 spec.policy.enforcer 字段中设置要使用的强制访问控制器。

策略模式​

vArmor 的策略可以运行在五种模式中：AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling 和 DefenseInDepth。这种灵活性使其能够满足不同场景的需求。

更多信息请参见 Policy Modes。

内置规则和自定义规则​

当安全策略运行在 EnhanceProtect 模式时，内置规则 和 自定义规则 可以被用于加固容器。此时，策略采用 Allow-by-Default 安全模型，这意味着只有明确声明的行为才会被阻止。这种方法在增强可用性的同时最大限度地减少了对性能的影响。

前置条件​

不同强制访问控制器所需的前置条件如下表所示。

强制访问控制器要求推荐
AppArmor1. Linux Kernel 4.15 及以上版本
2. 系统需开启 AppArmor LSM		GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
VKE with veLinux 1.0
Debian 10 及以上版本
Ubuntu 18.04.0 LTS 及以上版本
veLinux 1.0 等
BPF1. Linux Kernel 5.10 及以上版本 (x86_64)
2. containerd v1.6.0 及以上版本
3. 系统需开启 BPF LSM		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 等

* 需手动启用节点的 BPF LSM
Seccomp1. Kubernetes v1.19 及以上版本所有 Linux 发行版

快速入门​

Step 1. 拉取 chart 包​

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

Step 2. 安装​

vArmor 默认支持 AppArmor 和 Seccomp enforcer。请参照 配置选项 查看更多信息。

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

您可以在中国地区使用 elkeid-cn-beijing-1.cr.volces.com 域名

Step 3. 尝试以下用例​

创建 demo 命名空间。

kubectl create namespace demo

创建一个运行在 AlwaysAllow 模式 中的 VarmorPolicy 对象，为符合 spec.target.selector 条件的 deployments 开启“防护”。

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

查看 VarmorPolicy 和 ArmorProfile 对象的状态。

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

获取目标 Deployment 的 Pod 名称。

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

在容器 c1 中执行命令，读取其 SA token。

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

切换 VarmorPolicy 对象到 EnhancedProtect 模式，并阻止 c1 容器读取 SA 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

在容器 c1 中执行命令，读取其 SA token。验证读取行为是否被禁止。

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

演示​

下面是一个使用 vArmor 对 Deployment 进行加固，防御 CVE-2021-22555 攻击的演示（Exploit 修改自 cve-2021-22555）。

更多演示请查看我们的 GitHub 仓库。

image