Ubuntu服务器容器化之后，安全边界从单台主机扩展到了镜像、容器运行时、编排层和内核共享层面。很多团队把容器当成轻量级虚拟机来用，结果就是默认配置直接上生产，导致攻击面比传统部署更大。真正有效的安全防护不是装一个工具，而是从镜像构建、运行时限制、网络隔离到主机加固形成一套可落地的组合策略。

先说镜像层。绝大多数容器入侵的起点是基础镜像带漏洞或者镜像里塞了不必要的组件。建议固定使用Ubuntu LTS的官方精简镜像作为基础，不要直接使用latest标签，而是锁定到具体版本号，例如ubuntu:22.04。构建时用多阶段构建，把编译依赖留在中间层，最终运行镜像只保留二进制和最小运行库。每次构建后用工具扫描镜像漏洞，Ubuntu生态下可以直接使用trivy或grype，扫描结果接入CI流程，发现高危漏洞直接阻断发布。

# 多阶段构建示例
FROM ubuntu:22.04 AS builder
RUN apt-get update && apt-get install -y build-essential
COPY src/ /src/
RUN make -C /src

FROM ubuntu:22.04
COPY --from=builder /src/app /usr/local/bin/app
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates \
    && rm -rf /var/lib/apt/lists/*
USER 10001
ENTRYPOINT ["/usr/local/bin/app"]

镜像签名同样关键。生产环境只允许运行经过签名的镜像，可以使用cosign对镜像做签名验证，配合容器运行时的准入策略，防止被篡改的镜像上线。私有镜像仓库必须开启认证和最小权限，定期清理旧镜像，避免历史版本中的漏洞被重新拉取利用。

容器运行时安全的核心是限制权限。默认情况下容器以root运行，一旦逃逸或利用内核漏洞，宿主机直接沦陷。每个容器必须配置非root用户运行，在Dockerfile中显式声明USER。同时启用Linux capabilities裁剪，只保留业务必需的能力，例如NET_BIND_SERVICE用于绑定低端口，其他如SYS_ADMIN、NET_ADMIN、DAC_OVERRIDE全部移除。Docker下可以用--cap-drop ALL --cap-add NET_BIND_SERVICE，Kubernetes中通过securityContext配置。

# Kubernetes Pod安全上下文示例
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
  seccompProfile:
    type: RuntimeDefault

只读根文件系统是另一个容易被忽略的加固点。容器运行时用--read-only挂载根文件系统，业务需要写临时文件时单独挂载tmpfs或emptyDir。这样即使应用被攻破，攻击者也无法在容器文件系统内植入持久化后门。同时设置no-new-privileges，防止进程通过setuid提权。

seccomp和AppArmor是Ubuntu原生的内核安全机制，必须启用。Docker默认会加载seccomp配置文件，但很多团队为了省事直接--security-opt seccomp=unconfined，等于自废武功。生产环境应使用RuntimeDefault或自定义的seccomp profile，只允许必要的系统调用。AppArmor方面，Ubuntu提供了docker-default profile，容器化应用可以进一步编写针对具体业务的profile，限制文件访问路径和网络操作。如果使用Kubernetes，可以通过AppArmor注解为Pod指定profile。

内核隔离方面，如果业务允许，优先使用gVisor或Kata Containers这类强隔离运行时。它们把容器系统调用拦截在用户态或轻量级虚拟机中，即使容器被攻破，攻击者也难以触及宿主内核。对于多租户环境或者运行不可信代码的场景，这是比单纯seccomp更可靠的防线。Ubuntu 22.04可以直接安装containerd-shim-runsc-v1或kata-containers，在Kubernetes中通过RuntimeClass指定。

网络隔离不能只靠默认的桥接网络。生产环境应该为每个应用创建独立的Docker网络或Kubernetes NetworkPolicy，默认拒绝所有入站流量，只放行明确声明的端口和来源。容器之间如果需要通信，必须通过服务发现或显式的网络策略放行。对于对外暴露的服务，前置反向代理或负载均衡器，容器本身不直接绑定公网IP。Docker的端口映射尽量绑定到127.0.0.1而不是0.0.0.0，减少暴露面。

# Kubernetes NetworkPolicy示例：默认拒绝入站，仅允许同命名空间特定标签访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-policy
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

宿主机加固是容器安全的地基。Ubuntu服务器本身要开启自动安全更新，使用unattended-upgrades定期安装安全补丁。防火墙用ufw或nftables，只开放SSH和业务端口，Docker的端口映射会绕过ufw规则，所以要在DOCKER-USER链中显式配置iptables规则，防止容器端口被外部直接访问。SSH禁用密码登录，只允许密钥认证，并限制来源IP。

审计和日志是发现入侵的关键。Docker的日志驱动要配置为json-file或journald，并集中收集到日志平台。同时开启Docker daemon的审计日志，记录所有容器创建、启动、停止、镜像拉取等操作。Ubuntu可以用auditd监控/var/lib/docker目录和容器运行时二进制文件的变化。Kubernetes环境必须开启审计日志，重点记录exec、attach、portforward等高危操作。

资源限制不只是性能问题，也是安全防线。没有限制的容器可能因为内存耗尽触发OOM，或者CPU占满影响宿主机上其他服务。每个容器必须设置内存和CPU上限，Docker用--memory和--cpus，Kubernetes用resources.limits。同时限制容器的PID数量，防止fork炸弹拖垮宿主机。存储方面限制容器可写层大小，避免日志暴涨填满磁盘。

密钥管理是容器化部署中最容易出事的环节。不要在镜像中硬编码密码、API密钥或证书，也不要用环境变量传递敏感信息，因为环境变量会出现在docker inspect和进程列表中。生产环境使用专门的密钥管理方案，Ubuntu下可以部署HashiCorp Vault，或者使用Kubernetes的Secret配合外部加密存储。Docker Swarm模式下可以使用docker secret，但要注意secret在容器内以文件形式挂载，权限必须限制为只读且仅对运行用户可见。

容器编排层的安全同样不能忽视。Kubernetes的API Server必须启用RBAC，按最小权限原则分配角色，禁止使用cluster-admin跑业务Pod。Pod安全准入从v1.25开始取代了PodSecurityPolicy，建议启用restricted级别，强制非root、禁止特权模式、限制卷类型和capabilities。节点上kubelet的匿名访问必须关闭，API Server与kubelet之间的通信启用TLS认证。

针对容器逃逸的检测，可以在宿主机上部署运行时安全监控工具，例如Falco。Falco基于内核模块或eBPF监控系统调用，能够检测到容器内执行shell、挂载敏感目录、修改系统文件等异常行为。规则可以自定义，例如检测容器内尝试挂载/proc或/sys目录、尝试加载内核模块、尝试修改/etc/passwd等。告警接入SIEM或即时通讯工具，做到实时响应。

最后是备份和应急响应。镜像和容器配置要纳入版本管理，Dockerfile、compose文件、Kubernetes清单全部存放在Git仓库中，任何变更走代码审查流程。定期演练容器被入侵后的恢复流程，包括隔离容器、导出日志、分析镜像层、重建环境。Ubuntu服务器本身用timeshift或rsync做系统快照，容器数据卷用存储快照或定期备份，确保即使出现安全事件也能快速回滚。

容器化部署的安全防护不是一次性配置，而是持续的过程。镜像要持续扫描，运行时策略要随业务变化调整，内核补丁要及时更新，日志要持续监控。把上述措施落地到CI/CD流水线和基础设施即代码中，才能在享受容器化带来的部署效率同时，把安全风险控制在可接受范围内。