核心是绑定程序、定义行为、分阶段启用：先用aa-genprof生成基础策略，人工精简路径与权限（如/var/log/nginx/ rw, /etc/nginx/ r），再重载并切换enforce模式验证，最后联动容器环境挂载策略。
直接为关键服务程序配置AppArmor策略，核心是“绑定程序、定义行为、分阶段启用”。它不依赖用户身份，而是锁定该程序能读什么、写什么、连什么、执行什么——哪怕以root运行，也逃不出规则范围。
明确目标程序并生成基础策略
先确认服务二进制路径，例如Nginx通常在/usr/sbin/nginx，MySQL在/usr/bin/mysqld。用aa-genprof自动生成初始策略：
- 运行sudo aa-genprof /usr/sbin/nginx，系统会提示你操作Nginx（如访问网页、重载配置），期间AppArmor在complain模式下记录所有实际行为
- 记录完成后，工具自动将日志转为/etc/apparmor.d/usr.sbin.nginx策略文件，并进入编辑环节
- 此时策略默认宽松，需人工审查：删掉明显冗余项（如对/tmp的全权限），保留真实需要的路径和权限
编写关键访问规则（按需精简）
策略文件中每条规则对应一个资源访问声明。重点控制以下几类：
- /var/log/nginx/** rw, —— 允许读写所有Nginx日志，但限定在/var/log/nginx/目录内
- /etc/nginx/** r, —— 配置目录只读，防止运行时被篡改
- /run/nginx.pid rw, —— PID文件需读写，用于进程管理
- network inet stream, —— 仅允许TCP流式网络连接（禁用UDP或raw socket）
- /usr/sbin/nginx mr, —— 主程序自身可执行（m=memory map, r=read）
注意：路径通配符**表示递归子目录，*只匹配单层；权限字母r（读）、w（写）、x（执行）、l（链接）、m（内存映射）要按最小必要原则设定。
切换到enforce模式并验证效果
策略写完后不能直接上线，需分步验证：
- 用sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx重载策略
- 检查是否生效：sudo aa-status | grep nginx，应显示enforce状态
- 手动触发可疑操作测试，比如尝试echo "test" > /etc/nginx/nginx.conf，应被拒绝并记录到/var/log/audit/audit.log或/var/log/syslog
- 若服务异常，先查日志定位被拦行为，再回到complain模式补充规则，避免“一上就挂”
与容器环境联动（如CRI-O或Docker）
在Kubernetes或容器平台中部署时，AppArmor策略需显式挂载：
- 确保节点已加载策略：sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
- Pod注解中指定策略名（不是文件路径）：container.apparmor.security.beta.kubernetes.io/nginx: runtime/default 或自定义名如nginx-strict
- CRI-O默认使用crio-default策略，如需覆盖，需在runtimeClass或podSecurityContext中声明apparmorProfile: nginx-strict
- 注意：容器内进程路径可能与宿主机不同（如/bin/nginx），策略文件名和路径规则需同步调整
