生产环境使用 Docker Compose 部署时，security_opt 配置的核心是启用 no-new-privileges 防止权限提升，配合 seccomp 和 AppArmor 策略限制系统调用，这是容器运行时加固的基础措施。

命令速用版

以下是 docker-compose.yml 中 security_opt 的标准配置示例，可直接复制到你的项目中使用：

version: '3.8'
services:
  app:
    image: nginx:1.25-alpine
    security_opt:
      - no-new-privileges:true
      - seccomp:unconfined
    read_only: true
    cap_drop:
      - ALL

如果需要自定义 seccomp 策略文件，配置方式如下：

security_opt:
  - seccomp:/path/to/seccomp-profile.json
  - apparmor:/path/to/apparmor-profile

为什么会这样

security_opt 是 Docker 运行时传递到底层安全模块的配置选项，主要作用于三个层面：no-new-privileges 防止进程通过 setuid 等方式提升权限；seccomp 过滤容器可执行的系统调用，阻止危险操作；AppArmor 或 SELinux 基于策略限制进程对文件、网络的访问。

默认情况下，Docker 会启用默认的 seccomp 策略，但不会自动设置 no-new-privileges。生产环境中如果容器以 root 用户运行且没有这些限制，一旦应用存在漏洞，攻击者可能通过提权获得容器内更高权限，甚至尝试逃逸到宿主机。

根据容器安全加固实践，这些配置的本质是落实最小权限原则——容器只拥有完成自身工作所必需的权限，其他一律收掉。

分步处理

第一步：评估容器权限需求

在添加 security_opt 之前，先确认容器是否需要特殊权限。检查现有配置中是否有 privileged: true 或 cap_add 相关设置，如果有，记录原因并评估是否可以移除。

第二步：添加 no-new-privileges 配置

在 docker-compose.yml 的 service 级别添加以下配置：

security_opt:
  - no-new-privileges:true

这个配置会阻止容器内任何进程获取新的权限，即使进程以 root 身份运行也无法执行 setuid 操作。

第三步：配置 seccomp 策略

Docker 默认启用 seccomp，但生产环境建议审查或定制策略。如需使用自定义策略：

security_opt:
  - seccomp:/etc/docker/seccomp/custom-profile.json

策略文件需要预先准备好，可以从 Docker 官方默认策略基础上修改，移除不必要的系统调用。

第四步：配合其他安全配置

security_opt 应与其他安全措施配合使用，包括 cap_drop 丢弃所有能力、read_only 挂载只读根文件系统、user 指定非 root 用户运行。

第五步：回滚预案

如果配置后容器启动失败，先临时注释 security_opt 相关行，确认是安全配置导致的问题后再逐步排查。保留一份未加固的配置文件作为应急回滚用。

怎么验证是否生效

配置完成后，通过以下方法验证安全选项是否正确应用：

检查容器配置：

docker inspect <容器名> | grep -A 10 SecurityOpt

输出中应包含 no-new-privileges 和 seccomp 相关配置。

验证 no-new-privileges：

进入容器尝试执行需要提权的操作，如：

docker exec -it <容器名> sh
chmod u+s /bin/sh

如果配置生效，该操作会被拒绝或无法实际提升权限。

检查系统调用限制：

使用 strace 或类似工具观察容器内进程的系统调用，确认被 seccomp 策略阻止的调用会返回 EPERM 错误。

日志检查：

查看 Docker 守护进程日志，安全策略触发时通常会有相关记录：

journalctl -u docker | grep -i seccomp

常见坑

坑一：seccomp 策略过严导致容器无法启动

自定义 seccomp 策略如果阻止了容器启动必需的系统调用，容器会启动失败。建议从官方默认策略开始修改，每次只移除少量系统调用并测试。

坑二：no-new-privileges 与某些应用冲突

部分应用（如需要 setuid 的工具）在 no-new-privileges 启用后无法正常工作。这种情况下需要评估是否真的需要该功能，或考虑在单独容器中运行。

坑三：忽略 AppArmor/SELinux 状态

security_opt 中的 apparmor 配置需要宿主机启用对应安全模块。如果宿主机未启用 AppArmor，相关配置不会生效但也不会报错，容易形成安全假象。

坑四：特权模式覆盖安全配置

如果同时设置了 privileged: true，大部分 security_opt 配置会被忽略。生产环境应禁止使用特权模式，除非有明确且无法替代的需求。

坑五：配置后未验证功能

安全加固后必须验证业务功能是否正常。有些配置可能不会阻止容器启动，但会在特定操作时触发问题，需要在测试环境充分验证后再部署到生产。

参考来源

• 从零到生产：Docker 部署 Vault 密钥管理系统的完整安全指南 - 关键安全配置解析中提到 security_opt: no-new-privileges 防止容器内权限提升
• 生产环境安全加固——AI 教你学 Docker - 容器运行时安全部分提到 seccomp 配置方式 docker run `--security-opt` seccomp=/path/to/seccomp-profile.json
• 深入理解与实践：Docker 容器安全加固与策略 - 高级安全实践部分提到 Seccomp 和 AppArmor 配置方法
• Docker 容器安全加固实战 (Seccomp 策略深度配置手册) - 介绍 seccomp 工作原理与系统调用拦截机制
• Docker 生产环境安全加固指南 (附检查清单) - 整体加固思路强调最小权限原则落地