Docker 容器安全加固如何禁止 privileged 特权模式启动

生产环境中应默认禁止使用 privileged 模式，除非业务明确需要操作宿主机设备或进行容器嵌套，大多数场景可以通过细粒度能力替代。

先说结论：privileged 模式会让容器获得近乎宿主机的 root 权限，默认应禁止，仅在无法通过能力拆分时使用。

先判断：确认业务是否真的需要访问宿主机设备或修改内核参数。
优先做：改用 `--cap-add` 添加特定能力，或挂载具体设备文件。
再验证：检查容器启动配置和运行时权限，确保功能正常且权限最小化。

命令速用版

检查正在运行的容器是否开启了特权模式（已修复表头处理问题）：

docker ps `--format` "{{.Names}}\t{{.ID}}" `--no-trunc` | while read name id; do
  priv=$(docker inspect `--format` '{{.HostConfig.Privileged}}' $id)
  if [ "$priv" == "true" ]; then echo "WARNING: $name is privileged"; fi
done

启动容器时显式指定不需要特权模式（默认即为 false，但建议明确管控）：

docker run `--rm` -it `--cap-add` NET_ADMIN `--cap-add` SYS_TIME ubuntu:latest bash

为什么会这样

privileged 标志位会让容器内的 root 用户获得宿主机 root 的大部分能力。具体来说，它会启用所有 Linux capabilities，允许容器访问宿主机所有设备，并通常使 AppArmor 或 SELinux 等安全模块对该容器失效。这意味着如果容器被攻破，攻击者更容易逃逸到宿主机。这是容器安全基线中的高危项，CIS Docker Benchmark 明确建议禁止使用。

分步处理

1. 审计现有容器

使用上述检查命令扫描线上运行容器。如果是 Docker Compose 项目，检查 docker-compose.yml 文件中是否存在 privileged: true 字段。

2. 替换为细粒度权限

如果容器需要修改时间，不要给 privileged，改用 `--cap-add` SYS_TIME。如果需要操作网络，改用 `--cap-add` NET_ADMIN。如果需要访问特定硬件，使用 `--device` 挂载具体设备文件，而不是给全部权限。注意：部分 CapAdd 能力（如 SYS_ADMIN）依然具有较高风险，需严格评估。

3. Kubernetes 环境配置

在 K8s 集群中，建议使用 Pod Security Standards (PSS) 限制特权容器。通过给 Namespace 打标签来 enforce 策略：

apiVersion: v1
kind: Namespace
metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest

配置为 baseline 或 restricted 级别后，创建 privileged: true 的 Pod 将被拒绝。

4. CI/CD 流水线集成

在构建或部署阶段加入检查脚本，防止特权配置进入生产环境。示例脚本片段：

# 在部署前检查 docker-compose.yml 或 Kubernetes manifests
grep -r "privileged: true" ./
if [ $? -eq 0 ]; then
  echo "Error: Privileged mode detected in configuration"
  exit 1
fi

怎么验证是否生效

使用 docker inspect 查看具体字段确认：

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

返回 false 或未输出 true 即为正常。同时检查 CapAdd 列表，确认只包含了业务必需的能力：

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

还可以进入容器内部，尝试执行原本需要特权才能做的操作（如 mount 宿主机文件系统），确认是否被拒绝。

常见坑

1. Docker in Docker 场景

在 CI 环境中运行 Docker in Docker 时，很多教程习惯直接给 privileged。建议改用 Docker Socket 挂载或 rootless Docker 方案，避免直接特权启动。

2. 老旧镜像兼容

部分老旧镜像编写时不规范，依赖特权模式读写宿主机路径。这类镜像建议重构或替换，不要为了兼容而放宽安全策略。

3. 守护进程配置误区

标准 Docker Engine 社区版没有 daemon.json 配置项能全局禁止 privileged 参数传递，主要靠流程和扫描工具管控。不要轻信网上声称修改某个配置即可全局封锁的说法，除非使用企业版授权插件或外部策略工具。

参考来源

Docker Official Documentation, "Run container with additional capabilities", docs.docker.com
CIS Docker Benchmark, "Ensure that privileged containers are not used", Section 5.2.1
Kubernetes Documentation, "Pod Security Standards", kubernetes.io