Kubernetes 容器 AppArmor 字段原生化迁移：配置实操、访问控制验证与回滚

长期以来，Kubernetes 社区一直依赖 container.apparmor.security.beta.kubernetes.io/<container-name> 这一 Pod 注解机制来配置 AppArmor 策略。这种注解不仅破坏了 YAML 资源清单的结构化规范，也给准入控制（Admission Webhook）以及策略引擎（如 Kyverno、OPA/Gatekeeper）的校验带来了额外解析负担。随着 Kubernetes 对 AppArmor 机制的重构，原生 securityContext.appArmorProfile 字段逐步确立为标准配置方式（Kubernetes 1.30 进入稳定支持阶段，并在 1.31 达到正式 GA）。云安全工程师与集群运维人员面临将旧版注解平稳过渡到原生字段的运维任务，本文将围绕配置语法迁移、节点策略预置、系统访问边界验证以及回滚应急流程进行详细说明。

架构演进与配置语法迁移

在旧版实现中，每个容器的策略名称需要拼接在 Pod 的 Annotations 中，难以进行跨层级继承或统一验证。而在原生架构下，AppArmor 成为 securityContext 内部的一等公民对象，既可以定义在 Pod 级别生效于所有容器，也可以在容器级别覆盖全局设置。

字段对比与迁移映射

原生 appArmorProfile 对象由 type 和可选的 localhostProfile 组成，其映射关系如下：

生产清单配置对比

在改造 Deployment 或 Pod 资源时，推荐将通用安全基线提升至 spec.securityContext，对于具有特殊权限诉求的初始化容器或业务容器，在容器级别单独覆盖：

# 迁移前：旧版注解方式
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  annotations:
    container.apparmor.security.beta.kubernetes.io/web: runtime/default
    container.apparmor.security.beta.kubernetes.io/sidecar: localhost/custom-network-profile
spec:
  replicas: 2
  template:
    metadata:
      name: payment-service
    spec:
      containers:
        - name: web
          image: internal/payment:v1.2.0
        - name: sidecar
          image: internal/logger:v1.0.1

# 迁移后：原生 securityContext 方式
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 2
  template:
    metadata:
      name: payment-service
    spec:
      # Pod 级默认继承 RuntimeDefault
      securityContext:
        appArmorProfile:
          type: RuntimeDefault
      containers:
        - name: web
          image: internal/payment:v1.2.0
        - name: sidecar
          image: internal/logger:v1.0.1
          securityContext:
            # 容器级别精确指定节点预置策略
            appArmorProfile:
              type: Localhost
              localhostProfile: custom-network-profile

需要注意准入行为的变化：在官方 Kubernetes 配置安全上下文文档 中明确指出，如果容器显式声明了 type: RuntimeDefault，而目标节点未启用或不支持 AppArmor LSM，调度器与 Kubelet 将拒绝准入该 Pod；如果未显式声明，则仅在节点支持时默认应用。

节点准备与策略预置

当选用 type: Localhost 时，AppArmor 依赖宿主机内核装载的策略名称（而非文件绝对路径）。由于 Pod 调度具有不确定性，自定义策略必须提前在集群所有候选工作节点上同步加载。

1. 节点环境检查

首先登录集群工作节点，确认内核已加载 AppArmor 模块且服务处于活跃状态：

# 确认内核模块支持
sudo aa-status

# 检查 apparmor 服务状态
sudo systemctl status apparmor

若 aa-status 报错或显示 AppArmor 未激活，必须先在操作系统层（如 Ubuntu/Debian）安装并启动 apparmor 与 apparmor-utils 服务。

2. 编写并装载自定义限制策略

假定我们需要对某类关键应用执行更为严格的文件系统访问防护，限制其对 /sys、/proc/sys 等敏感路径的非常规写入操作。在节点 /etc/apparmor.d/containers/custom-hardened-profile 编写策略文件：

#include <tunables/global>

profile custom-hardened-profile flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  # 允许读取常见基础运行库与证书
  /etc/ssl/** r,
  /etc/resolv.conf r,
  /etc/hosts r,

  # 拒绝所有对 /proc 与 /sys 敏感核心参数的写入
  deny /proc/sys/** wklx,
  deny /sys/** wklx,
  deny /proc/kcore rwklx,
  deny /proc/mem rwklx,

  # 允许应用目录执行
  /app/** rix,
  /tmp/** rw,
}

在节点解析并加载该 profile：

# 校验并强制装载策略
sudo apparmor_parser -r -W /etc/apparmor.d/containers/custom-hardened-profile

# 验证策略是否已载入内核
sudo aa-status | grep custom-hardened-profile

对于大规模集群，推荐使用 DaemonSet 结合特权配置挂载宿主机 /etc/apparmor.d 路径，或借助节点初始化脚本（如 Cloud-Init、Ansible）自动化分发与装载。

访问控制验证与行为排查

策略应用后，必须分别从应用层防护边界和底层审计记录两个维度验证其有效性。

1. 验证进程受限状态

部署应用后，在集群控制面检查 Pod 运行状态，并登录对应节点验证容器实际绑定的 profile：

# 检查 Pod 运行状态
kubectl get pod payment-service-xxx -o wide

# 查看容器进程在节点上的 AppArmor 约束状态
kubectl exec -it payment-service-xxx -c sidecar -- cat /proc/1/attr/current

若命令输出返回 custom-hardened-profile (enforce)，表明进程已成功受控于自定义策略；若返回 cri-containerd.apparmor.d (enforce) 或 docker-default (enforce)，则说明当前处于 RuntimeDefault 状态；若返回 unconfined，则说明防护未生效。

2. 模拟越权行为触发防御

进入受保护容器，尝试触发已被规则屏蔽的特权路径写入：

# 尝试向 /proc/sys 写入系统参数（应被硬性拦截）
kubectl exec -it payment-service-xxx -c sidecar -- sh -c "echo 1 > /proc/sys/kernel/sysrq"

此时终端应直接抛出 sh: write error: Permission denied。值得注意的是，即便容器以 root 用户运行或被赋予了特定的 linux Capabilities，AppArmor 仍然会基于 Mandatory Access Control（MAC）机制先行切断该操作。

3. 内核审计排查日志

当业务容器遭遇非预期的 Operation not permitted 或崩溃中断时，可通过节点内核日志确认是否被 AppArmor 阻断：

# 在宿主机上检索内核审计日志中的拦截记录
sudo dmesg -T | grep -i "apparmor="DENIED""
# 或通过 audit 守护进程查询
sudo ausearch -m AVC -ts recent

一条典型的阻断记录如下：

type=AVC msg=audit(1715012345.678:421): apparmor="DENIED" operation="open" profile="custom-hardened-profile" name="/proc/sys/kernel/sysrq" pid=12345 comm="sh" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

运维人员可据此分析阻断发生的进程名称（comm）、触发路径（name）与操作权限（requested_mask），以此微调 profile 内容。

生产变更故障应急与策略回退

在批量迁移旧有工作负载时，如果因 profile 缺失、权限收敛过严导致业务 Pod 启动报 CrashLoopBackOff、CreateContainerError，需按照既定步骤实施平滑回滚。

常见故障排查检查表

1. CreateContainerError 阶段报错 profile not found：
2. 原因：工作节点未装载 Pod 中声明的 localhostProfile，或策略名称拼写有误。
3. 处理：检查 aa-status 中已载入策略清单；若需紧急启动容器，可将其回退到 type: RuntimeDefault。
4. 节点未启用 AppArmor 导致调度排斥：
5. 原因：显式设置了 type: RuntimeDefault，但个别异构混合节点（如基于 RedHat/CentOS 开启 SELinux 体系的节点）未启用 AppArmor 内核模块。
6. 处理：通过 nodeSelector、Taints/Tolerations 将 Pod 限制在装有 AppArmor 的节点组，或移除显式指定依赖默认行为。

紧急回滚路径

在发生大面积阻断时，可分两级执行回退：

方案 A：降级至容器运行时默认基线（推荐）

直接将出故障的工作负载修改为 RuntimeDefault，维持基础防御的同时解除自定义规则冲突：

kubectl patch deployment payment-service --type='json' -p='[
  {"op": "replace", "path": "/spec/template/spec/containers/1/securityContext/appArmorProfile", "value": {"type": "RuntimeDefault"}}
]'

方案 B：紧急临时放行（仅限应急）

如果应用涉及旧版本复杂本地权限调试，可快速切换为 Unconfined 放行：

kubectl patch deployment payment-service --type='json' -p='[
  {"op": "replace", "path": "/spec/template/spec/containers/1/securityContext/appArmorProfile", "value": {"type": "Unconfined"}}
]'

方案 C：降级回退至旧版本注解

如果集群控制面版本兼容性存在冲突（例如管理控制器在老版本 Kubernetes 产生歧义），移除 securityContext.appArmorProfile 并重置为注解：

# 移除原生字段
kubectl patch deployment payment-service --type='json' -p='[
  {"op": "remove", "path": "/spec/template/spec/securityContext/appArmorProfile"},
  {"op": "remove", "path": "/spec/template/spec/containers/1/securityContext/appArmorProfile"}
]'

# 重新打上旧版注解
kubectl annotate deployment payment-service 
  "container.apparmor.security.beta.kubernetes.io/sidecar=runtime/default" --overwrite

通过将 AppArmor 迁移至 securityContext.appArmorProfile 原生字段，团队不仅可以使清单结构符合统一的安全配置标准，还能与内置的 Pod 安全性标准 (Pod Security Standards) 体系更紧密地结合。结合节点自动化策略同步与审计排查，能够在最大化减小容器攻击面的同时，保障云上生产业务的连续与稳定。