BehaviorModeling 模式
介绍
BehaviorModeling 模式是一个实验功能。您可以利用 BehaviorModeling 模式在指定时间范围内收集并处理目标工作负载的行为,对其进行行为建模。一旦建模结束,vArmor 会生成一个 ArmorProfileModel 对象,用来保存目标工作负载的行为模型。
行为模型可以被用于分析哪些内置规则能够被用于加固目标应用,或者指导用户对工作负载的安全上下文进行权限最小化。
当前只有 AppArmor 和 Seccomp enforcer 支持 BehaviorModeling 模式。
前置条件
vArmor 当前利用一个内置的 BPF tracer 和 Linux 审计系统来捕获目标应用的行为。
BehaviorModeling 模式的前置条件如下所示:
-
containerd v1.6.0 及以上版本
-
系统需支持 BTF (BPF Type Format)
一般来说,当节点存在
/sys/kernel/btf/vmlinux文件时,意味着系统支持 BTF。 -
vArmor 启用了此特性
-
通过
--set behaviorModeling.enabled=true选项开启 BehaviorModeling 特性。 -
[可选] 使用
--set "agent.args={--auditLogPaths=FILE_PATH|FILE_PATH}"选项来指定系统审计日志或搜索顺序。
helm upgrade varmor varmor-0.7.1.tgz \
--namespace varmor --create-namespace \
--set image.registry="elkeid-cn-beijing.cr.volces.com" \
--set behaviorModeling.enabled=true注意:
-
vArmor 顺序检查对应的审计日志是否存在,并通过监控第一个有效的文件来获取 AppArmor 和 Seccomp 的审计事件,从而用于违规审计和行为建模功能。当您使用 auditd 时,AppArmor 和 Seccomp 的审计事件会默认保存在
/var/log/audit/audit.log文件中。否则,他们通常会被保存在/var/log/kern.log文件中。 -
启用 BehaviorModeling 特性时,varmor-agent 需要如下所示的追加资源。另外,varmor-classifier 组件也会被部署,用于识别路径中的随机字符串。
resources:
limits:
cpu: 2
memory: 2Gi
requests:
cpu: 500m
memory: 500Mi
-
使用说明
基本用法
使用 BehaviorModeling 功能的基本步骤如下所示。
1. 创建 BehaviorModeling 模式的策略
您可以通过 .spec.policy.modelingOptions.duration 字段设置建模时长,并在建模完成前按需调整。您还可以通过 .spec.updateExistingWorkloads 字段设置是否对符合条件的目标工作负载进行滚动重启(仅支持 Deployment, DaemonSet, StatefulSet 类型的目标工作负载),从而立即开始行为建模。
apiVersion: crd.varmor.org/v1beta1
kind: VarmorPolicy
metadata:
name: demo-4
namespace: demo
spec:
# Perform a rolling update on existing workloads.
# It's disabled by default.
updateExistingWorkloads: true
target:
kind: Deployment
selector:
matchLabels:
app: demo-4
policy:
enforcer: AppArmorSeccomp
# Note: 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: DefenseInDepth
mode: BehaviorModeling
modelingOptions:
# The duration in minutes to modeling
duration: 3
2. 创建符合条件的目标工作负载
如果 updateExistingWorkloads=true 且目标工作负载的类型不为 Pod,那么您可以跳过此步骤。否则您应当创建新的符合条件的工作负载。
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-4
namespace: demo
labels:
app: demo-4
# This label is required with target workloads.
# You can disable the feature with --set 'manager.args={--webhookMatchLabel=}'
sandbox.varmor.org/enable: "true"
spec:
replicas: 2
selector:
matchLabels:
app: demo-4
template:
metadata:
labels:
app: demo-4
annotations:
# Use these annotation to explicitly disable the protection for the container named c0.
# It always takes precedence over the '.spec.target.containers' field of VarmorPolicy
# or VarmorClusterPolicy object.
container.apparmor.security.beta.varmor.org/c0: unconfined
container.seccomp.security.beta.varmor.org/c0: unconfined
spec:
shareProcessNamespace: true
containers:
- name: c0
image: curlimages/curl:7.87.0
command: ["/bin/sh", "-c", "sleep infinity"]
imagePullPolicy: IfNotPresent
- name: c1
image: debian:10
command: ["/bin/sh", "-c", "sleep infinity"]
imagePullPolicy: IfNotPresent
3. 更新建模时长(按需)
您可以根据需要,通过更新策略的 .spec.policy.modelingOptions.duration 字段来修改建模时长。例如将其修改为 1 从而提前结束建模。
kubectl patch vpol -n demo demo-4 --type='json' -p='[{"op": "replace", "path": "/spec/policy/modelingOptions/duration", "value":1}]'
4. 等待建模完成
$ kubectl get vpol -n demo
NAME ENFORCER MODE TARGET-KIND TARGET-NAME TARGET-SELECTOR PROFILE-NAME READY STATUS AGE
demo-4 AppArmorSeccomp BehaviorModeling Deployment {"matchLabels":{"app":"demo-4"}} varmor-demo-demo-4 true Modeling 2s
$ kubectl get vpol -n demo
NAME ENFORCER MODE TARGET-KIND TARGET-NAME TARGET-SELECTOR PROFILE-NAME READY STATUS AGE
demo-4 AppArmorSeccomp BehaviorModeling Deployment {"matchLabels":{"app":"demo-4"}} varmor-demo-demo-4 true Completed 30m
建模完成后,agent 会对在节点上采集到的(目标工作负载的)行为数据进行预处理,然后将其发送到 manager。而 manager 将对所有节点采集的数据进行分析,并将其保存在对应命名空间的 ArmorProfileModel 对象的 .data.dynamicResult 字段中。
manager 处理完所有节点的行为数据后,它会以白名单方式(Deny-by-Default)为目标工作负载生成 AppArmor 或 Seccomp Profile,并保存在 ArmorProfileModel 对象的 .data.profile.content 和 .data.profile.seccompContent 字段中。
当数据量过大导致无法保存在 CRD 对象中时,manager 会将其保存在本地。您可以通过 ArmorProfileModel 对象的 .storageType 字段判断行为数据和 Profile 的存储形式。
$ kubectl get ArmorProfileModel -A
NAMESPACE NAME STORAGE-TYPE DESIRED COMPLETED READY AGE
demo varmor-cluster-demo-demo-4 CRDInternal 2 2 true 23h
注意事项
- 目标工作负载需要拥有
sandbox.varmor.org/enable="true"标签。您可以通过 设置 Webhook 的匹配标签 配置选项关闭此特性。 - 不支持将 BehaviorModeling 模式的策略切换为其他模式,反之亦然。您需要删除策略后重新创建策略才可切换。
- 建模完成后,不支持修改策略的建模时长。您需要删除策略后重新创建策略才可以重新开始建模,但已有的行为数据会被保留。
数据导出
您可以将目标负载的行为数据和 Profiles 导出用于其他目的。例如:使用 策略顾问 分析哪些内置规则能够被用于加固目标应用 ,基于行为数据指导用户对工作负载的安全上下文进行权限最小化等。
不同存储类型的 ArmorProfileModel 对象导出方法不同:
-
CRDInternal
-
直接使用 kubectl 导出
kubectl get ArmorProfileModel -n demo varmor-demo-demo-4 -o json > varmor-demo-demo-4.json
-
-
LocalDisk
-
将本地端口 8080 转发到集群 varmor-status-svc Service 的 8080 端口
kubectl port-forward -n varmor service/varmor-status-svc 8080:8080 -
获取 varmor-manager 的 ServiceAccount token
token=$(kubectl create token varmor-manager -n varmor)
-