我们运维香港数据中心一批运行Kubernetes的裸金属服务器时，发现其中某些容器能够越权访问宿主机的部分系统资源，经过深入排查，最终定位为namespace泄漏问题。本文将详细还原整个排查与修复过程，展示 Linux namespace 隔离机制的实现与风险点，帮助运维与研发人员深入理解容器环境下的潜在安全隐患。
一、故障现象与初步判断
1. 异常行为
开发人员反馈，在一台运行高性能计算（HPC）服务的 Kubernetes 节点（位于香港）中，其容器内可以访问到其他容器的 /proc 信息，包括网络连接、进程信息等，甚至能观察到宿主机上运行的进程。
通过对容器执行以下命令：
docker exec -it suspicious-container bash
cat /proc/1/cgroup
返回值显示：
0::/
说明该容器未正确挂载 CGroup 控制组，且可能未被正确隔离。
进一步检查网络 namespace：
lsns | grep net
结果显示某些容器与宿主机共享了同一个 network namespace，这种情况在未显式配置 –network host 的前提下是不正常的。
2. 涉及环境
- 宿主机操作系统：CentOS 7.9
- 内核版本：3.10.0-1160.el7.x86_64
- Docker 版本：19.03.15
- Kubernetes 版本：v1.20.15
- 容器运行时：Docker（未使用 Containerd）
二、技术原理解析
1. Linux namespace简介
Linux 提供了多种 namespace 类型，用以实现资源隔离：
- PID namespace：进程隔离
- NET namespace：网络隔离
- MNT namespace：文件系统挂载点隔离
- UTS namespace：主机名、域名隔离
- IPC namespace：进程通信隔离
- USER namespace：用户和组 ID 隔离
- CGROUP namespace：控制组隔离
容器正常运行时，Docker 会为每个容器自动创建并分配独立的 namespace，确保进程间不会互相干扰。
2. 泄漏的可能原因
本次故障可能涉及以下几种原因：
- 容器创建参数错误：如误用了 –pid=host、–net=host
- 宿主机内核 bug：部分旧版本内核存在 namespace 无法正确隔离的已知漏洞
- CNI 插件异常：网络插件配置错误导致 namespace 被篡改
- Kubernetes 配置缺陷：Pod 的安全策略未启用正确的限制
三、排查过程详解
1. 确认namespace泄漏类型
使用 lsns 命令查看 namespace ID：
ps -eo pid,comm,nsnet,nspid,nsmnt,nsuts,nsipc,uid,gid | grep <container-pid>
发现该容器与宿主机具有相同的 namespace ID，进一步印证了隔离失效的现象。
2 检查容器创建参数
使用如下命令导出容器配置：
docker inspect <container-id> | jq '.[0].HostConfig'
部分容器显示以下参数：
"NetworkMode": "host",
"PidMode": "host",
"Privileged": true
明显这些配置打破了 namespace 的隔离性，特别是 Privileged=true，容器可以拥有宿主机的大量权限。
3. 检查 Kubernetes 安全策略
查看 Pod YAML 定义：
spec:
hostNetwork: true
hostPID: true
containers:
- name: hpc-container
securityContext:
privileged: true
这个配置等同于在 Docker 中显式使用 –net=host、–pid=host 以及 –privileged，显然这是人为配置失误。
四、解决方案与加固建议
1. 修复当前问题
立即下线不合规容器：
kubectl delete pod hpc-container -n compute
调整 Pod 配置：
移除 hostNetwork、hostPID 和 privileged 配置项：
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
重建容器并验证 namespace 隔离：
docker exec -it safe-container bash
lsns -p 1
2. 加固Kubernetes集群安全
启用 PodSecurityPolicy 或 PodSecurity Admission（Kubernetes v1.25+）：
限制容器使用 hostNetwork、hostPID、privileged 权限。
使用容器运行时安全工具：
例如 Open Policy Agent（OPA）、Seccomp、AppArmor 进行强制执行策略。
升级内核版本：
- 建议升级至 RHEL 8 或更高内核，解决旧版本可能存在的 namespace 漏洞。
- 构建受控镜像仓库与部署规范：
- 审计镜像权限与启动参数，避免使用 root 用户、共享宿主机资源。
五、数据支撑与后续观察
通过对香港节点上 142 台物理服务器的审计，有 13 台服务器存在 namespace 配置异常的容器，占比约 9.1%。经过统一修复后，系统日志未再出现宿主机资源越权访问的记录。
我们通过 Prometheus 和 Falco 监控数据确认：
- 容器访问 /proc 的行为明显下降
- 容器间进程通信尝试减少 94%
- 系统安全事件告警从每日平均 21 次降至 2 次
六、优化与建议
本次namespace泄漏事件揭示出容器配置不当可能带来的严重安全隐患。作为容器平台的管理者，需充分理解Linux提供的隔离机制，并结合Kubernetes的资源限制机制，形成统一的规范与策略。
建议企业在生产环境中：
- 明确哪些服务需要特权模式
- 定期审计容器namespace隔离状态
- 强化DevSecOps流程，将安全“左移”
- 加强对 CNI、CRI 组件版本与配置的管控
通过本次实战，我们不仅解决了一个影响范围较广的故障，更进一步提升了整个容器平台的安全防护能力。
