Docker中daemon配置与docker run设置seccomp的差异及验证方法

两种配置方式回顾 #

1. Docker Daemon全局配置
   在daemon配置文件（通常为/etc/docker/daemon.json）中添加自定义profile路径，修改后需重启Docker daemon生效：

{
    "seccomp-profile": "/etc/docker/custom-seccomp.json",
    ...
}

重启命令：systemctl restart docker

2. 容器启动时单独指定
   执行docker run命令时通过--security-opt参数为单个容器指定profile：

$ docker run --rm \
             -it \
             --security-opt seccomp=/path/to/your-profile.json \
             hello-world

两种配置方式的差异 #

• 优先级差异：容器启动时指定的profile会直接覆盖Daemon全局配置。即全局配置了A profile，启动容器时指定B profile，容器会采用B的规则。
• 作用范围差异：Daemon配置是全局默认规则，对所有未单独指定profile的容器生效；docker run指定的规则仅作用于当前启动的单个容器。
• 灵活性差异：全局配置适合统一管控所有容器的系统调用权限，启动时指定则可针对不同业务容器配置差异化规则，比如给敏感容器设置更严格的限制。

Daemon配置是否对所有容器生效 #

是的，但存在例外情况：

• 所有未在启动时通过--security-opt seccomp指定自定义profile的容器，都会默认使用Daemon配置的规则。
• 如果启动容器时明确指定了profile，该容器会忽略全局配置，采用指定的规则。
• 若启动时使用--security-opt seccomp=unconfined，会完全禁用seccomp限制，同样跳过全局配置。

验证配置是否生效 #

方法1：查看容器的seccomp配置详情

使用docker inspect命令查看容器的安全选项：

docker inspect --format '{{.HostConfig.SecurityOpt}}' <容器ID或名称>

• 输出若包含seccomp=/path/to/your-profile.json，说明容器使用了指定的自定义profile。
• 若Daemon配置了全局自定义profile且容器未单独指定，输出会显示Daemon配置的路径。
• 未配置全局自定义时，Docker默认使用内置profile，输出通常不会显示seccomp路径。

方法2：测试被限制的系统调用

1. 创建测试用的seccomp profile（比如禁止mkdir系统调用），保存为test-seccomp.json：

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "mkdir",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

2. 用该profile启动容器：

docker run --rm -it --security-opt seccomp=./test-seccomp.json alpine

3. 在容器内执行mkdir testdir，若返回mkdir: can't create directory 'testdir': Operation not permitted，说明seccomp配置已生效。

内容的提问来源于stack exchange，提问作者everyDay0