文章总结： 本文介绍了Dockerfile的基础知识及其安全问题。主要发现包括以root用户运行容器、网络隔离不足、敏感信息硬编码等风险。可操作建议包括使用非特权用户、限制端口暴露、避免硬编码敏感信息、限制资源使用、选择最小化基础镜像、实施多阶段构建、设置只读文件系统，并集成漏洞扫描工具如Trivy。遵循最小权限原则和及时更新可阻断多数攻击路径。
综合评分： 100
文章分类： 安全建设,云安全,应用安全,数据安全,安全运营
dockerfile文件简介以及安全问题
原创
信安路漫漫
信安路漫漫
2025年7月31日 07:00
上海
前言
现在很多公司选择了业务上云，在业务上云的过程中一定会接触到dockerfile文件的编写，今天就来学习一下dockerfile文件的编写以及可能存在的安全问题。
dockerfile简介
Dockerfile 是 Docker 的核心配置文件，用于自动化构建 Docker 镜像（Image）。它本质上是一个包含构建指令的文本文件，定义了如何将应用程序及其依赖打包成可移植的容器镜像。
Dockerfile 的核心作用
| | |
| — | — |
| 场景 | 作用 |
| 环境标准化 | 确保开发、测试、生产环境完全一致（”一次构建，处处运行”） |
| 依赖管理 | 自动化安装操作系统工具、语言运行时、库文件等依赖 |
| 应用部署 | 将应用程序代码/二进制文件复制到镜像中并配置启动方式 |
| 安全加固 | 通过定制用户权限、最小化基础镜像减少攻击面 |
| 镜像分层优化 | 利用层缓存机制加速构建，减小镜像体积 |
Dockerfile 基础语法与常用指令
# 1. 指定基础镜像（必须放在第一行）FROM ubuntu:22.04# 2. 设置元数据（非必须）LABEL maintainer="[email protected]"# 3. 设置工作目录（后续命令的相对路径）WORKDIR /app# 4. 复制本地文件到镜像COPY ./src /app/src# 5. 安装系统依赖（每行RUN生成一个镜像层！）RUN apt-get update && apt-get install -y \ python3 \ python3-pip# 6. 安装应用依赖（利用层缓存优化）COPY requirements.txt .RUN pip install --no-cache-dir -r requirements.txt# 7. 暴露容器端口EXPOSE 8000# 8. 设置默认启动命令CMD ["python3", "app.py"]
关键指令
| | | |
| — | — | — |
| 指令 | 作用 | 示例 |
| FROM | 指定基础镜像（必须第一个指令） | FROM node:16-alpine |
| COPY vs ADD | 优先用 COPY ， ADD 会自动解压文件且行为不可预测 | COPY ./src /app/src |
| RUN | 执行命令并创建新层，用 && 合并命令减少层数 | RUN npm install && npm run build |
| CMD | 容器启动时的默认命令（可被 docker run 覆盖） | CMD [“python”, “app.py”] |
| ENTRYPOINT | 固定容器主进程（与 CMD 组合使用） | ENTRYPOINT [“python”] |
| ARG | 构建时传递变量（构建后消失） | ARG APP_ENV=prod |
| ENV | 设置持久环境变量（容器运行时仍存在） | ENV NODE_ENV=production |
镜像构建与使用流程
-
编写 Dockerfile在项目根目录创建 Dockerfile（无后缀名）
-
构建镜像
docker build -t my-app:latest . # -t指定镜像名称，`.`表示当前目录
- 验证镜像
docker images # 查看生成的镜像
- 运行容器
docker run -d -p 8080:8000 --name my-app-container my-app:latest
dockerfile文件的安全问题
1. 特权用户风险
问题
默认以root运行容器，一旦被入侵则宿主系统面临威胁（如篡改系统文件）。
解决
RUN groupadd -r appgroup && useradd -r -g appgroup appuser # 创建非特权用户USER appuser # 切换用户CMD ["python", "app.py"]
📌 同时需确保数据卷权限：RUN chown -R appuser:appgroup /data
#
#
2. 网络隔离不足
问题
容器默认共享宿主网络命名空间，暴露不必要的端口和服务。
解决
限制端口暴露：
EXPOSE 8000 # 仅暴露必需端口
运行时隔离：
docker run --network=my_bridge_network ... # 使用自定义
桥接网络
#
#
3. 敏感信息泄露
问题
在Dockerfile或镜像中硬编码密码、API密钥：
ENV DB_PASSWORD="123456" # 危险！
解决
构建时传参：
ARG DB_PWDRUN echo $DB_PWD > /app/secrets.txt && rm -f /app/secrets.txt # 临时使用后删除
构建命令：docker build –build-arg DB_PWD=xxx .
运行时注入：
docker run -e DB_PASSWORD=$(vault read secret/db) ...
#
4. 资源滥用攻击
问题
未限制CPU/内存，恶意进程可能导致宿主资源耗尽。
解决
Dockerfile声明（需配合运行时参数生效）：
# 提示管理员需在运行时限制资源LABEL resource_limit="Require --cpus and --memory flags"
运行时限制：
docker run --cpus=2 --memory=1g --pids-limit=100 ...
#
#
5. 依赖漏洞与供应链攻击
问题
基础镜像含漏洞或npm install下载恶意包。
解决
选择最小化基础镜像：
FROM python:3.11-slim # 而非 python:3.11
校验依赖完整性：
RUN npm ci --audit # 检查npm包漏洞
多阶段构建隔离构建环境：
FROM node:18 AS builderRUN npm install # 高风险操作在此阶段FROM nginx:alpineCOPY --from=builder /app/dist /usr/share/nginx/html # 仅复制编译结果
#
#
6. 文件系统安全
问题
容器可写层被恶意写入或篡改关键文件。
解决
设置只读根文件系统：
docker run --read-only ...
卷挂载敏感目录：
VOLUME /tmp # 允许临时写入RUN chmod 1777 /tmp # 限制粘滞位
#
#
7. 能力(Capabilities)过度授权
问题
默认授予NET_RAW等危险能力（如可用ping发动DDoS）。
解决
移除非必要能力：
# Dockerfile中无法直接设置，需在运行时处理：LABEL drop_caps="Require --cap-drop=ALL --cap-add=NET_BIND_SERVICE"
运行命令示例：
# Dockerfile中无法直接设置，需在运行时处理：LABEL drop_caps="Require --cap-drop=ALL --cap-add=NET_BIND_SERVICE"
💎 终极防御策略
| | |
| — | — |
| 措施 | 实现方式 |
| 镜像漏洞扫描 | 集成Trivy/Clair到CI流程，阻断含高危漏洞的镜像部署 |
| Seccomp配置文件 | 限制容器系统调用： docker run –security-opt seccomp=profile.json … |
| AppArmor/SELinux | 强制访问控制策略： docker run –security-opt apparmor=my_profile … |
⚠️ 关键提醒：超80%的容器逃逸源于配置缺陷（如特权模式+旧内核漏洞）。遵循最小权限原则、及时更新基础镜像、配合运行时防护，可阻断99%的攻击路径34。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：信安路漫漫 信安路漫漫《dockerfile文件简介以及安全问题》