Docker 运行时加固清单：权限、凭据与镜像签名
Docker 运行时加固清单：权限、凭据与镜像签名
示例场景：容器若以默认 root 身份运行且挂载宿主机/var/run/docker.sock，攻击者一旦获得容器执行权限，可能借 Docker API 影响宿主机。基础镜像遗留构建工具也会扩大攻击面。容器加固不能只看镜像体积，还要检查权限、凭据和供应链风险。
graph TD A[容器安全防线体系] --> B[入口一: 运行时权限剥离] A --> C[入口二: 密钥挂载与内存泄露防范] A --> D[入口三: 供应链签名与漏洞卡槽] B --> B1[非 root 用户 + ReadOnly 文件系统 + Capability 裁剪] C --> C1[严禁 ENV 明文 + tmpfs 临时挂载] D --> D1[Cosign 镜像签名 + Trivy CVE 依赖拦截]运行时权限剥离：非 Root 用户、Capabilities 裁剪与 ReadOnly 根文件系统
默认情况下，容器内 UID 0 通常映射为宿主机的 UID 0；用户命名空间会改变这一关系。非 root 运行不能消除内核漏洞等风险，但能缩小部分误用和提权路径。
安全加固的首要步骤是在 Dockerfile 中显式指定无特权的运行身份（USER），并在容器启动参数中剥离非必要的 Linux 内核特权（Capabilities）。
# 生产级加固 Dockerfile FROM alpine:3.19 # 创建低权限专用用户组与用户 RUN addgroup -g 10001 appgroup && \ adduser -u 10001 -G appgroup -h /app -s /sbin/nologin -D appuser WORKDIR /app COPY --chown=appuser:appgroup ./binary /app/server # 切换为无特权用户运行 USER 10001:10001 ENTRYPOINT ["/app/server"]配合容器运行时的启动参数配置，可进一步开启根文件系统只读（ReadOnlyRootfs）并丢弃所有内核 Capability：
docker run -d \ --name secure-service \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64m \ --cap-drop=ALL \ --cap-add=NET_BIND_SERVICE \ --security-opt=no-new-privileges:true \ my-app-image:v1启用只读根文件系统后，应用需要的写目录应显式挂载。noexec,nosuid能限制 tmpfs 中的执行和特权位，但仍应按应用需要验证目录权限。
使用终端命令可以核对容器运行时的 Linux Capability 配置是否成功裁剪：
docker inspect --format='{{.HostConfig.CapDrop}} | {{.HostConfig.ReadonlyRootfs}}' secure-service演练终端打印的拟真安全校验输出：
[示例输出] Security Audit Check: CapDrop=[ALL], ReadonlyRootfs=true, User=10001.尝试在加固容器内部创建文件时，系统将精准触发异常边界并拒绝请求：
[示例输出] bash: /etc/test.txt: Read-only file system入口二：凭据挂载与 Docker Socket 套接字隔离防范
第二个容易被忽略的入口是凭据明文泄露与宿主机套接字的滥用。严禁在生产环境容器中直接挂载 /var/run/docker.sock 接口，除非该 Pod 属于经过安全审计的专用 CI Runner。
对 API Key、数据库密码等敏感参数，应避免将值写入镜像层或日志。可通过受控的文件挂载、Kubernetes Secret 或专用密钥服务提供，并配合最小访问权限和轮换策略。
应用读取凭据时应当增加内存读取防错机制，在凭据导入后立即在内存中进行脱敏与销毁句柄：
import os def load_security_credential(secret_path: str = "/var/run/secrets/db_password") -> str: """从内存卷中读取凭据并在读取后验证权限""" if not os.path.exists(secret_path): raise FileNotFoundError(f"未能在路径 {secret_path} 提取凭据") stat_info = os.stat(secret_path) # 防错规则: 限制文件权限必须为 0400 或 0600 (仅所有者可读) if stat_info.st_mode & 0o077 != 0: raise PermissionError("凭据文件权限过宽，存在被同机其他进程窃取风险") with open(secret_path, "r") as f: credential = f.read().strip() return credential try: token = load_security_credential() except Exception as e: print(f"凭据加载拦截: {e}")在持续集成阶段，需要运行工具检查 Docker 镜像中是否含有遗留的 .env 文件或敏感路径挂载：
trivy fs --security-checks config,secret /path/to/project示例演练中，凭据未落入镜像层或临时目录。文件挂载和 tmpfs 并不能阻止已获取进程权限后的内存读取，仍需缩小进程权限并限制调试、转储能力。
入口三：镜像供应链签名与 Cosign 验签卡槽
第三个入口是镜像供应链漏洞与未授权镜像替换风险。即使容器运行时配置无懈可击，如果拉取的镜像被恶意篡改注入了后门代码，整体防护体系依然会被瓦解。
生产环境可建立镜像签名和准入校验。Cosign 可在 CI 阶段签名；在 Kubernetes 中需由 Kyverno、Gatekeeper 的相应策略或其他准入组件执行校验。cosign verify本身是命令行验证，不会自动成为集群准入规则。
在 CI 流水线中生成签名并推送到私有仓库的命令：
cosign sign --key cosign.key my-registry.local/apps/my-app:v1在集群准入控制阶段验签镜像的命令：
cosign verify --key cosign.pub my-registry.local/apps/my-app:v1拟真演练的验签终端控制台日志如下：
[示例输出] Cosign verification header parsed. Signature matches the configured identity and issuer policy.启用准入验签后，应分别测试已签名、未签名、身份不匹配和签名过期的镜像，并记录准入延迟。只有这些用例都符合策略，才能说明规则按预期工作。
运行时权限、凭据管理和供应链签名是三项基础控制。是否满足合规要求还取决于组织的基线、审计和持续运营措施。