很多人对容器的安全有个朴素又危险的假定："装了 Docker、容器有隔离，就安全了。"实际上，容器与宿主共享内核，隔离是"相对但不绝对"的——默认配置下容器往往以 root 用户运行、带一堆默认权限、其镜像可能藏着一层又一层过时的依赖，一旦被攻破可能殃及宿主机。容器安全加固做的是把这几件事逐个收紧：让容器不以 root 跑、削减 Linux capabilities、启用更强隔离与只读文件系统、对镜像做扫描与信任管理。这篇讲清容器安全的真实威胁面、最小加固动作、镜像安全与信任，以及边界，帮你在自托管里把"容器化"用得更稳。
一、先认清威胁面：容器安全不是"有隔离就完事"
容器安全的关键事实是：容器和宿主机共享同一个内核。这意味着容器内的"root"、容器所拥有的 capability、它能否访问宿主设备/文件，都取决于你怎么配置——很多默认配置其实给了比应该有的权限更多的面。威胁面主要来自三处：一是"以 root 跑"——容器内默认就是 root，一旦被攻破，它有内核这份共享资源的更大操作余地；二是"镜像里的脆弱依赖"——很多被打包进去的库早已过时、带有已知漏洞，镜像本身就是把攻击面照搬进来；三是"该关掉的隔离没关"——安全相关的 Linux capabilities 默认开得较宽，能做超出预期的事。
所以健康的思考不是"容器有没有隔离"而是"我给的隔离边界够不够紧"：通过在镜像与运行时两个层面加固，把"一旦出问题的后果"尽量收窄。自托管尤其如此——你往往跑一堆不常打补丁的服务，若不把边界收紧，感染一个就可能波及宿主上其它数据。把"默认不信任、最小权限、及时扫描"当成容器安全的底色。
二、最小加固动作：非 root、只读、删特权
第一波最小加固往往是性价比最高的。其一是"不用 root 跑"：在 Dockerfile 里用 `USER nobody`（或建专用低权用户）让容器内的进程以非特权用户运行，直接砍掉"容器 root"这个最危险面。其二是"拿掉多余 capabilities"：用 `--cap-drop=ALL`（Docker）或 `cap_drop: ALL`（Compose）先丢掉全部，再 `--cap-add` 只补运行确需的那几个——绝大多数普通应用都够。其三是"只读根文件系统"：把不写的部分挂成只读、需要写的地方单独用数据卷，让"一旦被写坏也不至于改写容器本身"。
# Dockerfile / compose 里的最小加固示意
# Dockerfile 中：用非 root 用户运行
FROM alpine:3.20
RUN adduser -D app && chown -R app /app
USER app
ENTRYPOINT ["/app/appbinary"]
# compose 中：丢权限 + 只读文件系统
services:
app:
image: myapp:latest
cap_drop: [ALL] # 先丢全部 capabilities
cap_add: [NET_BIND_SERVICE] # 再只补确需的
read_only: true # 根只读
tmpfs: [ /tmp ] # 必要的临时目录放内存
这三招合起来，能在不改动应用逻辑的情况下显著收窄运行层面。一个现实提醒：改非 root 后有些应用会在某些路径上写失败，所以要么先把临时目录放 tmpfs、把要写的路径挂成可写卷，要么逐个验证；而 capabilities 加得越少越好、只补"缺了这个跑不起来"的。把这些当成每个新容器部署的默认检查项，而不是"出了问题再来加固"。
三、镜像安全：扫描漏洞、用对基础镜像、控制来源
光运行层面收紧不等于镜像本身干净。镜像安全要抓三件事。一是"扫描"：用镜像漏洞扫描工具（如 trivy）在构建/部署前扫镜像，看看基础镜像与运行依赖有没有已知 CVE，决策是否升级；二是"用对基础镜像"：优先选体积小、受维护、及时更新的官方基镜（alpine/slim 等），别锁死在老版本上让 CVE 越积越多；三是"管好来源与信任"：只用信任、可核验的镜像源，别随便 pull 来路不明的镜像，体现的都是一种"默认不信任"。
# 用 trivy 扫镜像漏洞（示例，需先安装）
# trivy image myapp:latest
# 关注 HIGH/CRITICAL 与基础镜像 CVE，决定是否升级基镜/依赖版本
# 可把扫描接入 CI，在部署前拦下含高危漏洞的镜像
镜像安全不是一次性的：基础镜像与依赖会随时间暴露新 CVE，所以要"定期重扫 + 保持可升级路径"，而不是"装好的镜像永远不变"。给自托管者的实用节奏：在部署流程里加"构建后扫描 + 定期重扫 + 高危漏洞升级"这套，配合 `Dockerfile` 里选维护中的基镜，镜像层面对已知漏洞的暴露就持续可控。把它当成日常运维的一部分，而不是部署前的一次应激动作。
四、网络与数据边界：默认不信任、最小互联
容器安全还有一个常被忽略的轴：容器之间、容器与宿主的网络边界。默认情况下容器网络相对隔离，但如果你不控制，一个被攻破的容器可能横向移动。收窄它的动作包括：容器监听端口只暴露到需要的层（前面反代统一入口，别裸开一堆公网端口）；关键服务之间按需最小连，避免"所有容器都能互访所有东西"；数据卷的权限与宿主路径控制好，别让容器对宿主文件有过广的写权限。
# 网络收紧示意（compose）
services:
app:
expose: ["8080"] # 只暴露给 Compose 内部网络，不对外开端口
proxy: # 唯一真正对外的入口由反代承担
ports: [ "443:443", "80:80" ]
# 别让数据库/后端把端口也拉到公网，只让反代/必要服务能访问它们
把"端口只从该有的地方露出去、服务之间最小互访、数据卷权限最小化"落实，你就在"网络横向移动"这条路上设了很好的闸。别忘了给容器名对应的服务也保持最小权限与监控——一个被攻破的低权限、只读、仅最小互联的容器，往往"爆"不了多大的雷。边界收得越紧，出问题时波及面越小，这正是容器安全加固追求的本质。
五、边界：加固降风险，不等于绝对安全，也别为了安全废开心
再三强调边界：容器安全加固是把风险"大幅收窄"，不是"零风险"。历史上有过容器/内核逃逸的漏洞，而且应用本身的逻辑漏洞、弱口令、过期依赖这些，安全加固与隔离并不能替你挡住——所以加固要和服务层认证、防火墙、备份、监控组合使用，而不是"我加了隔离就高枕无忧"。另一方面也要避免"为安全而安全"矫枉过正到过度拖累使用：只加"确需、有依据"的隔离与限制，凡是改动都先在测试验证不破坏功能。
务实做法是分层：先做"非 root + 丢特权 + 只读 + 扫描 + 最小网络"这套基础，它们成本低、收益高、几乎必做；再按风险确认要不要上更强的隔离（如专用运行时、更严格的 seccomp profile）。把"默认不信任、最小权限、及时扫描、持续升级"变成日常习惯后，容器就从"隔离给个心理安慰"变成你自托管里真正可控、可信的一层安全边界——既不大惊小怪，也不掉以轻心。
结语
容器安全加固的价值，是认清"容器共享内核"的威胁面，并通过"非 root、丢特权、只读根文件系统、镜像扫描、最小网络互联"把边界逐个收紧，让一个容器即使被攻破也不至于殃及宿主。落地要点：用 `USER` 非 root + `cap_drop` + `read_only` 做运行层加固；用 trivy 扫镜像 CVE、选维护中基镜并定期重扫升级；网络层只露必要端口、关键服务最小互联、数据卷权限最小化。边界是"加固收窄风险而非零风险"——要和防火墙、服务认证、备份监控组合使用，并避免矫枉过正影响可用性。把它当成每个容器部署的默认检查，你的容器化自托管才会从"图省事"升级为"隔离可信、边界受控"的长期安全基础。
