必须用非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）则引入风险。

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 脚本类文件必须可执行但无需写权限：
  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 中修改。容器应尊重宿主机安全基线，而非试图覆盖。