公司新上线的电商平台跑在容器里，开发团队觉得部署快、资源省，运维却天天提心吊胆。上周一次扫描发现，某个运行中的容器居然开着默认的SSH端口，镜像里还藏着一个老版本的OpenSSL——这不就是等着被攻击吗？
容器不是铁箱子，关上就安全
很多人以为容器隔离性好，把应用丢进去就万事大吉。其实容器共享宿主机内核，一旦底层存在漏洞或配置不当，攻击者能轻松逃逸到宿主机，进而控制整台服务器。比如一个未限制权限的容器，通过挂载宿主机的 /proc 文件系统，就能读取其他容器的数据。
常见的风险点藏在你看不见的地方：使用了带已知漏洞的基础镜像、容器以 root 权限运行、开放了不必要的端口、日志和配置文件混在镜像里。这些都可能成为突破口。
从镜像开始掐断风险链
构建镜像时，别图方便直接用 latest 标签。这个标签背后可能是任何版本，今天拉的是安全的，明天重建可能就变了。应该锁定具体版本号，比如 ubuntu:20.04 而不是 ubuntu:latest。
在 Dockerfile 里尽量用非 root 用户启动服务：
FROM nginx:alpine
RUN adduser -D myapp
USER myapp
CMD ["nginx", "-g", "daemon off;"]这样即使容器被攻破，攻击者的权限也被限制在普通用户级别。
运行时也得盯紧点
启动容器时，加上必要的安全选项。比如禁止写入关键目录、限制系统调用、关闭危险能力（capability）：
docker run --rm \
--read-only \
-v /tmp/myapp/session:/sessions \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
-p 8080:80 \
mywebapp这里设置了只读文件系统，只允许绑定网络端口所需的能力，其他统统禁掉。临时数据通过挂载外部卷解决。
别忘了资源限制。一个失控的容器占满CPU或内存，会影响同一宿主机上的所有服务。用 --memory 和 --cpus 参数设个上限。
日常监控不能偷懒
定期扫描镜像漏洞是基本操作。可以用 Trivy 这类工具集成到 CI 流程中：
trivy image myregistry.com/myapp:latest发现高危漏洞直接阻断发布流程。线上环境也要部署运行时监控工具，比如 Falco，它能捕捉异常行为，像容器试图修改自身二进制文件或者执行 shell 命令，立刻告警。
还有个小细节：别把敏感信息硬编码在镜像里。数据库密码、API密钥这些，一律通过环境变量或 secrets 管理工具注入。否则随便谁拿到镜像，解压一下就能看到全部家底。
某次事故就是因为开发者把测试环境的 Redis 密码写进了 Dockerfile，镜像上传到公共仓库后，没几天就被机器人扫走，用来挖矿去了。