容器与云服务器安全架构：从基线到运行时防护实战 核心要点图解，容器安全的前提是主机安全，宿主机基线不达标，运行时防护形同虚设。；禁止特权容器与 docker.sock 挂载，可消除大部分容器逃逸路径。；镜像必须固定 digest 并扫描，latest 标签等于把生产交给运气。；运行时防护看行为不看签名，异常 exec、敏感挂载、反弹连接是重点。
容器与云服务器安全架构：从基线到运行时防护实战 · 核心要点一图读懂（AegisX）

核心要点（TL;DR）

  • 容器安全的前提是主机安全，宿主机基线不达标，运行时防护形同虚设。
  • 禁止特权容器与 docker.sock 挂载，可消除大部分容器逃逸路径。
  • 镜像必须固定 digest 并扫描，latest 标签等于把生产交给运气。
  • 运行时防护看行为不看签名，异常 exec、敏感挂载、反弹连接是重点。

很多团队把容器当成「轻量虚拟机」，云服务器上直接 docker run --privileged 跑业务，宿主机防火墙全开、镜像用 latest、日志从不看。等到挖矿进程占满 CPU 才发现：容器里一个 Web 漏洞，攻击者顺着挂载的 docker.sock 就把整台云服务器拿下了。容器与云服务器安全架构不是买一个工具，而是从主机基线、镜像基线到运行时防护的三层收敛。下面按可执行顺序给出命令与清单。

一、先厘清边界：容器安全为什么必须从主机开始

容器与宿主机共享内核，隔离靠 namespace 与 cgroups，不是硬件虚拟化。这意味着任何内核提权漏洞、特权容器、敏感目录挂载，都可能把容器内的失陷放大为整台云服务器的失陷。安全架构的优先级应是：主机基线 > 镜像可信 > 运行参数收敛 > 运行时检测。前三层是「减少可被利用的面」，最后一层是「发现已经发生的事」。

二、主机与云服务器基线加固（可直接执行）

1. SSH 与账号

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
AllowUsers deploy

改完执行 sshd -t && systemctl reload sshd 验证，避免把自己锁在门外。

2. 防火墙只放行必要端口

ufw default deny incoming
ufw allow from 203.0.113.0/24 to any port 22
ufw allow 80,443/tcp
ufw enable && ufw status verbose

3. 关闭 Docker 远程 API 暴露

检查 ss -lntp | grep 2375，若有监听立即处理。守护进程配置中不要出现 -H tcp://0.0.0.0:2375；确需远程管理时走 SSH 隧道或 TLS 双向认证。

4. 用工具做一次完整体检

apt install lynis -y && lynis audit system
# 或
docker run --rm --pid=host aquasec/kube-bench:latest run --targets node

按报告中的 warning 逐项修复，重点关注内核参数、审计服务、文件权限与补丁状态。

三、镜像与运行参数：把攻击面在启动前收掉

镜像侧：固定 digest 而非标签，构建阶段扫描，基础镜像用 slim/alpine，移除编译工具与包管理器。

docker pull nginx@sha256:<digest>
trivy image --severity HIGH,CRITICAL nginx@sha256:<digest>

运行侧用一张对照表把高危参数钉死：

风险项错误写法推荐写法
权限--privileged按需 --cap-drop ALL --cap-add NET_BIND_SERVICE
用户默认 rootDockerfile 中 USER 10001
文件系统可写根目录--read-only --tmpfs /tmp
套接字挂载 docker.sock禁止挂载，改用受控 API 代理
网络host 网络自定义 bridge，仅映射必要端口

再加一层系统调用过滤：

docker run --security-opt seccomp=/etc/seccomp/default.json \
  --security-opt no-new-privileges \
  --read-only --tmpfs /tmp myapp:1.0

Kubernetes 环境对应设置 securityContext.runAsNonRoot: true、allowPrivilegeEscalation: false、readOnlyRootFilesystem: true，并用 NetworkPolicy 默认拒绝东西向流量。

四、运行时防护：看行为，不看签名

基线只能挡住已知配置错误，真正的入侵发生在运行过程中。运行时检测应聚焦四类行为：容器内异常 exec（如出现 shell、curl 下载）、敏感路径写入（/etc、/root/.ssh）、对外反弹连接、以及挂载点变化。

# 快速排查异常进程与网络连接
docker ps --quiet | xargs -I{} docker top {}
ss -antp | grep ESTAB
# 检查容器是否被提权运行
docker inspect --format '{{.HostConfig.Privileged}} {{.Config.User}}' $(docker ps -q)

生产环境建议接入基于 eBPF 的运行时检测，只采集进程执行、文件写入、网络连接等关键事件，避免全量拦截带来性能损耗。AegisX 在运行时防护侧提供容器行为基线建模与异常进程告警，可与上述主机基线、镜像扫描形成闭环，适合没有专职安全团队的中小站点快速补齐检测能力。

五、上线前检查清单

  • SSH 禁密码、禁 root 直登，来源 IP 白名单已生效。
  • 云服务器安全组与主机防火墙双层收敛，仅放行 80/443 与运维端口。
  • 所有镜像固定 digest，CI 中高危漏洞阻断构建。
  • 容器非 root 运行，禁用 privileged，不挂载 docker.sock 与宿主敏感目录。
  • 根文件系统只读，Seccomp 与 no-new-privileges 已开启。
  • 运行时告警已接入，异常 exec 与反弹连接有通知渠道。

六、行动建议

不要试图一次做完。本周先完成两件事：关闭 Docker 远程 API 暴露、把线上容器从 privileged 和非 root 两个维度过一遍 docker inspect；下周补镜像 digest 固定与 CI 扫描；最后再接运行时告警。每完成一层，用 lynis 或 kube-bench 复扫一次留档，形成可审计的安全基线记录。容器与云服务器安全架构的价值不在于工具数量，而在于每一层都有明确的责任人和可验证的检查项。

常见问题（FAQ）

容器里跑的服务被入侵，会不会直接拿下云服务器？

有可能。容器与宿主机共享内核，一旦容器以 root 运行、挂载了 docker.sock 或开启 privileged，攻击者就能通过内核漏洞或 Docker API 逃逸到宿主机。降低风险的关键是：容器内使用非 root 用户、禁止特权模式、不挂载敏感目录与套接字，并配合 Seccomp 与只读根文件系统限制系统调用和写入。

云服务器安全基线到底要检查哪些项？

优先检查五类：SSH 是否禁用密码登录并限制来源、防火墙是否只放行必要端口、系统与内核补丁是否及时、Docker 守护进程是否暴露 2375 端口、审计日志是否开启。可用 lynis 或 openscap 做一次扫描，再按报告逐项修复，比凭经验逐条查更快也更完整。

镜像扫描出高危漏洞，但业务依赖旧版本怎么办？

先确认漏洞是否在可达路径上，再决定处置优先级。可执行的步骤是：固定镜像 digest、替换基础镜像为精简版、删除不必要的编译工具与包管理器，对无法升级的组件用网络策略与 Seccomp 做补偿控制。扫描应接入 CI，在构建阶段阻断高危漏洞进入仓库，而不是等上线后再补。

运行时防护工具会不会拖慢业务性能？

通常影响很小，关键在采集方式。优先选择基于 eBPF 的方案，避免全量系统调用拦截；只对写操作、进程执行、网络连接等关键事件做检测，并对高频事件做聚合采样。上线前在预发环境压测对比 CPU 与延迟，确认开销在可接受范围再全量。

小团队没有安全专职人员，怎么低成本起步？

按「先收敛暴露面，再谈检测」的顺序做。第一步关掉公网不必要的端口和 Docker 远程 API；第二步统一容器运行参数，禁用特权、非 root 运行、只读根文件系统；第三步接入一个轻量运行时告警。这三步用配置模板加脚本就能完成，成本低且能挡住大多数自动化扫描与常见入侵。