Docker基础教程（259）Docker资源控制之强制访问控制工具AppArmor：容器安全的守护神：AppArmor如何让Docker容器不再“为所欲为”

云端安全，从给容器戴上“紧箍咒”开始

在容器技术席卷全球的今天，我们像造房子一样快速部署应用，但有没有想过，这些看似隔离的容器是否真的安全？当攻击者突破容器边界时，我们该如何守住最后一道防线？今天，我们要聊的就是Linux系统中的安全卫士——AppArmor，它就像是给容器量身定制的“行为规范手册”，告诉容器什么能做，什么绝对不能碰。

1 什么是AppArmor？为什么容器需要它？

AppArmor（Application Armor）是Linux内核的一个强制访问控制（MAC）系统，简单来说，它通过为每个应用程序分配一个安全配置文件，明确规定了该程序可以访问哪些系统资源，就像给每个程序分配了一个“权限清单”。

与传统的自主访问控制（DAC）不同，AppArmor采用的是白名单机制，即"未明确允许即为禁止"。这种机制在容器安全中尤为重要，因为即使攻击者成功入侵容器，AppArmor也能限制其进一步行动，防止容器逃逸攻击。

与另一种常见MAC系统SELinux相比，AppArmor有一个显著优势：基于路径的配置。这意味着管理员不需要理解复杂的标签系统，只需指定文件路径即可配置安全策略，大大降低了使用门槛。就像是指挥交通时，不需要知道每辆车的详细信息，只需要规定哪些道路可以通行一样简单直观。

为什么容器特别需要AppArmor？

默认情况下，Docker容器运行时虽然有一定的隔离，但仍有大量系统资源暴露给容器。没有AppArmor保护时，容器内的进程可能会：

• 访问敏感的主机文件系统
• 执行危险的系统调用
• 滥用内核功能进行权限提升

而AppArmor就像是容器的“贴身保镖”，时刻监控并限制容器的行为，确保它不会越界。

2 AppArmor基础：工作原理与核心概念

2.1 AppArmor如何工作？

AppArmor的核心工作原理可以概括为以下几个步骤：

1. 配置文件定义：系统管理员为特定应用程序创建配置文件，定义其允许访问的资源
2. 策略加载：通过apparmor_parser工具将配置文件加载到内核中
3. 执行监控：当受控应用程序运行时，Linux内核会拦截其访问请求，并与加载的策略进行比对
4. 决策执行：符合策略的访问被允许，违反策略的访问被拒绝并记录

2.2 两种工作模式

AppArmor有两种主要工作模式，适应不同的使用场景：

• 强制模式（Enforce）：在此模式下，AppArmor会主动阻止违反策略的操作，是生产环境的推荐模式。就像严格的交通警察，不仅记录违章，还会当场开罚单。
• 投诉模式（Complain）：此模式下，AppArmor仅记录违规行为而不阻止，适用于策略调试和测试阶段。这好比只记录不处罚的监控摄像头，用于了解程序正常运行需要哪些权限。

2.3 配置文件语法基础

AppArmor配置文件的语法相对直观，主要包含以下元素：

#include <tunables/global>  # 引入全局变量

profile docker-nginx flags=(attach_disconnected) {  # 定义配置文件
  #include <abstractions/base>  # 引入基础规则集

  capability net_bind_service,  # 允许绑定特权端口
  network inet tcp,            # 允许IPv4 TCP网络访问

  /etc/nginx/** r,             # 允许读取nginx配置目录
  /var/log/nginx/** w,         # 允许写入日志目录

  deny /etc/passwd rw,         # 明确拒绝访问密码文件
}

如上例所示，配置文件清晰定义了应用程序的权限边界，既允许必要访问，又明确拒绝危险操作。

3 在Docker中启用和配置AppArmor

3.1 检查系统环境

在开始之前，需要先确认你的