用 Kyverno 校验 AppArmor 配置

在 Kubernetes 中，仅检查 Pod 级别是否配置 AppArmor 并不足以保证所有容器都受到约束：容器级配置可以覆盖 Pod 级默认值。使用 Kyverno 制定准入策略时，关键是校验每个容器最终继承或显式指定的配置，而不是只确认某个字段存在。

确定允许的配置

可以将 RuntimeDefault 作为基线，并按需允许 Localhost。前者使用容器运行时的默认策略；后者通过 localhostProfile 指定节点上预先加载的策略名称。对于 Localhost，校验既要确认类型，也要检查策略名称是否符合组织的允许范围。Unconfined 则意味着不施加 AppArmor 限制，不应与受保护状态等同。

判断有效配置时，应先看容器自身的 securityContext.appArmorProfile；存在容器级设置时，以其为准，否则再检查 Pod 级设置。业务容器和初始化容器都需要纳入检查，避免 Pod 默认值合规、个别容器却通过覆盖设置绕过基线。若要求显式配置，也应拒绝两级均缺失的情况，而不是依赖节点支持时才生效的默认行为。

把准入校验与运行验证分开

Kyverno 校验的是提交的资源配置，不能仅凭清单证明目标节点已启用 AppArmor，也不能证明 Localhost 指定的策略已在候选节点加载。上线前仍需核对节点环境和策略分发状态；部署后还应检查容器进程的实际约束，并结合节点审计记录排查意外阻断。

实施时可先检查现有工作负载中的违规配置，再逐步收紧准入要求。若自定义策略导致业务故障，切换到 RuntimeDefault 可以作为保留基础约束的回退选择；改为 Unconfined 则需要明确其安全风险，并避免让临时例外成为长期默认配置。