在 docker-compose.yml 中通过 security_opt 统一配置 no-new-privileges:true、label=type:container_t，并配合 daemon 级 userns-remap=default，可批量加固多服务；需结合 user、read_only、cap_drop 等字段联动使用，并通过 /proc/1/status、ls -z、id 等命令验证生效。
直接在 docker-compose.yml 中配置 security_opt，是批量加固多服务最直接、最可控的方式。它不依赖镜像内部逻辑，也不改动 Docker daemon 全局设置，适合医疗、金融等强合规场景下的快速落地。
必须写入的三项核心配置
这三项不是可选项，而是等保2.0、HIPAA、STIG 等标准中反复出现的“高风险项修复依据”：
-
no-new-privileges:true：禁用容器内进程通过execve()提权（如调用 setuid 二进制或获取CAP_SYS_ADMIN），有效缓解 CVE-2023-28842 类逃逸链； -
label=type:container_t：为所有服务进程和挂载点打上 SELinux 标签，在 enforcing 模式宿主机上触发强制访问控制，阻止跨容器文件读写或非法端口绑定； -
userns-remap=default：需配合 Docker daemon 已启用用户命名空间映射（{"userns-remap":"default"}），让每个服务内的 UID 0 映射到宿主机无特权范围（如 100000–165535），切断 root 权限直通路径。
在 Compose 文件中统一声明的写法
不建议逐个服务重复写，应利用 YAML 锚点（anchor）实现一次定义、多处引用，避免遗漏或不一致：
version: '3.8'
x-security-base: &security-base
security_opt:
- no-new-privileges:true
- label=type:container_t
# 注意：userns-remap=default 不能写在 service 级别，必须由 daemon 全局启用
<p>services:
api-gateway:
</p><p>inference-engine:
</p>
- /tmp:rw,size=16m,exec
说明：
userns-remap是 daemon 级能力，security_opt中只负责“启用该能力下的隔离效果”，所以只需确保 daemon 已配置并重启，service 中无需再显式写入。
配合其他 runtime 约束提升实效性
单独靠 security_opt 不足以覆盖全部基线，建议与以下字段联动使用：
-
user：强制指定非 root UID/GID，与no-new-privileges形成双重防护； -
read_only: true：根文件系统只读，防止运行时篡改二进制或配置； -
cap_drop：默认丢弃全部 capability，按需用cap_add显式授权（如NET_BIND_SERVICE）； -
tmpfs：为/tmp、/run等可写路径提供内存挂载，避免写入磁盘且隔离临时数据。
验证是否生效的简易方法
部署后进入任一容器执行以下命令，确认关键策略已加载：
# 检查是否禁用提权 cat /proc/1/status | grep NoNewPrivs # 输出 1 表示生效 <h1>检查 SELinux 上下文</h1><p>ls -Z /proc/1/exe # 应显示 type=container_t</p><h1>检查 UID 映射效果（需 daemon 启用了 userns-remap）</h1><p>id # 容器内 uid=0，但宿主机上实际是 100000+ 范围 </p>
若某项未命中，优先检查 Docker daemon 是否已启用对应功能（尤其是 userns-remap 和 SELinux enforcing 模式），而非 Compose 配置本身。
