必须用非root用户运行Docker镜像，因其默认以root身份运行会带来提权和宿主机渗透风险；通过Dockerfile中显式创建非特权用户（如adduser）、使用USER指令切换身份、结合COPY --chown绑定文件属主，可有效遵循最小权限原则，显著降低攻击面。
Dockerfile 本身不直接配置内核参数（那是宿主机或容器运行时的事），但它能决定容器启动后的权限基线、文件归属、能力边界和运行身份——这些才是安全加固的起点。关键不是“加功能”，而是“减风险”。
明确运行用户，禁用 root
这是最有效也最容易被忽略的一环。默认以 root 运行，等于把容器大门钥匙交给应用进程。
- 在 Dockerfile 中显式创建非特权用户，并切换上下文：
RUN addgroup -g 1001 -f appgroup && \<br> adduser -S -u 1001 -u 1001 -G appgroup -s /bin/sh appuser
- 复制文件时就绑定属主，避免后续 chmod/chown 错误：
COPY --chown=appuser:appgroup ./app /opt/app - 最后强制切换用户：
USER appuser（该指令后所有 RUN 和 CMD 都以此用户执行）
固化文件权限，匹配运行身份
权限错配会导致应用启动失败或被迫回退到 root；而过度开放（如 777）则引入风险。
- 脚本类文件必须可执行但无需写权限：
RUN chmod +x /opt/app/entrypoint.sh - 配置文件只需读权限：
RUN chmod 644 /opt/app/config.yml - 敏感凭证（如 .env）仅限当前用户读写：
RUN chmod 600 /opt/app/.env - 日志目录需可写，且归属正确：
RUN mkdir -p /var/log/myapp && \<br> chown appuser:appgroup /var/log/myapp && \<br> chmod 750 /var/log/myapp
限制能力（Capabilities），按需最小化
Dockerfile 不支持直接写 cap-drop/cap-add，但可通过构建阶段提示+运行时约束实现闭环。关键是让镜像“天生就不该有高危能力”。
- 在 Dockerfile 注释中声明所需能力，作为交付契约：
# SECURITY: requires only NET_BIND_SERVICE, no SYS_ADMIN or NET_ADMIN - 避免使用
USER root或省略USER指令 - 不安装或保留不必要的工具（如
ip、mount、modprobe），从源头减少能力滥用可能
配合运行时策略，形成完整防线
Dockerfile 是静态定义，真正生效依赖运行时配置。建议将以下策略与镜像配套使用：
-
--read-only：根文件系统只读，防止恶意篡改 -
--cap-drop=ALL --cap-add=NET_BIND_SERVICE：丢弃全部能力，再精准添加 -
--user 1001:1001：双重保险，即使 Dockerfile 的 USER 失效也能兜底 -
--security-opt=no-new-privileges:true：阻止进程后续提权 -
--tmpfs /tmp:rw,noexec,nosuid,size=64m：提供安全临时空间
内核参数（如 kernel.randomize_va_space 或 vm.swappiness）由宿主机统一管理，不应也不可在 Dockerfile 中修改。容器应尊重宿主机安全基线，而非试图覆盖。
