1. 容器隔离的薄弱环节与lxcfs的切入点很多人做容器安全加固第一反应是配防火墙、限制CPU内存、扫镜像漏洞这些当然要做但真正让容器看起来隔离、实际漏风的地方往往藏在/proc和/sys这些伪文件系统里。我最早意识到这个问题是在一次内部压测中一个容器里跑free -m显示的内存居然是宿主机的总量而不是容器被限制的额度。当时第一反应是显示错了而已不影响实际使用但后来发现很多程序会根据free、/proc/cpuinfo、/proc/meminfo的返回值来决定自己开多少线程、分配多大缓冲区。容器里看到的是宿主机的资源视图程序就会按宿主机规模去申请资源结果要么被cgroup直接OOM杀掉要么把整台机器的负载拉爆。这就是lxcfs要解决的核心问题。lxcfs是一个用户态的FUSE文件系统它把/proc/meminfo、/proc/cpuinfo、/proc/stat、/proc/uptime、/proc/diskstats、/proc/swaps、/proc/slabinfo等文件劫持过来根据当前容器所属cgroup的限制值动态生成一份属于这个容器自己的视图。容器里free -m看到的就是自己的内存上限nproc看到的就是自己的CPU配额uptime看到的是容器启动时长而不是宿主机开机时长。为什么这件事对安全加固有意义因为隔离性不只是能不能访问还包括看到什么。一个容器如果能读到宿主机的真实内存总量、CPU核数、磁盘IO统计、开机时间攻击者就能据此推断宿主机规格、判断自己是否在容器中、估算横向移动的资源预算。信息泄露本身就是攻击链的一环。lxcfs把这类信息按容器维度伪装掉等于把侦察面收窄了一大块。需要说清楚的是lxcfs不是万能的。它只处理/proc下特定几个文件不处理/sys也不改变内核命名空间的实际隔离能力。它的定位是信息视图隔离和cgroup的资源限制、namespace的视图隔离是互补关系不是替代关系。我见过有人以为装了lxcfs就容器安全了这是误解。它只是加固拼图中的一块而且是一块容易被忽略、但补上之后收益很直接的拼图。下面我会从lxcfs的实际部署讲起然后说特权容器这个最容易出事的点再讲容器白名单怎么做才不是摆设最后把我自己整理的一套加固思路完整摊开。全程都是可复现的操作参数我会解释为什么这么设。2. lxcfs增强容器隔离性的落地细节2.1 lxcfs到底改了哪些文件为什么是这几个先把lxcfs覆盖的文件列清楚这决定了你装完之后能期待什么、不能期待什么。被覆盖的文件作用不覆盖会怎样/proc/meminfo内存总量、可用量容器内看到宿主机全部内存/proc/cpuinfoCPU型号、核数容器内看到宿主机所有核/proc/statCPU时间统计容器内看到宿主机全局CPU使用/proc/uptime系统运行时长容器内看到宿主机开机时长/proc/swapsswap使用情况容器内看到宿主机swap/proc/diskstats磁盘IO统计容器内看到宿主机磁盘活动/proc/slabinfo内核slab分配容器内看到宿主机内核对象/proc/loadavg系统负载容器内看到宿主机负载这几个文件的共同点是它们都是只读的、反映全局状态的、被大量程序读取的。lxcfs的做法是在这些路径上挂一个FUSE层读取时实时查询当前进程所在cgroup的限制值然后拼出一份假内容返回。注意是实时查询所以你在运行中调整cgroup限制容器里free的结果会跟着变不需要重启容器。2.2 部署lxcfs的完整步骤与参数解释我以主流的Linux发行版为例走一遍从安装到挂载的流程。不同发行版包名略有差异但逻辑一致。# 安装lxcfs包名通常是lxcfs # Debian/Ubuntu系 apt-get install -y lxcfs # RHEL/CentOS系需要先启用对应仓库 yum install -y lxcfs # 确认安装后的关键文件 # /usr/bin/lxcfs 主程序 # /var/lib/lxcfs 默认挂载点 # /etc/lxc/lxcfs.conf 配置文件安装完不要急着挂载先确认内核支持FUSElsmod | grep fuse # 如果没有输出加载它 modprobe fuse # 确认FUSE设备存在 ls -l /dev/fuse/dev/fuse必须存在否则lxcfs起不来。这是第一个容易踩的坑某些精简版系统镜像默认没带fuse模块装完lxcfs启动直接报cannot open /dev/fuse。启动lxcfs并挂载# 启动服务 systemctl start lxcfs systemctl enable lxcfs # 手动挂载如果服务没自动挂 mkdir -p /var/lib/lxcfs lxcfs /var/lib/lxcfs # 验证挂载 mount | grep lxcfs # 应该看到 fuse.lxcfs on /var/lib/lxcfs type fuse.lxcfs到这里lxcfs本身跑起来了但它还没对任何容器生效。关键一步是把宿主机的/var/lib/lxcfs/proc/meminfo等文件bind mount进容器的对应路径。这一步在Docker里通过-v参数完成docker run -it --rm \ --memory512m --cpus1 \ -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:ro \ -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:ro \ -v /var/lib/lxcfs/proc/stat:/proc/stat:ro \ -v /var/lib/lxcfs/proc/uptime:/proc/uptime:ro \ -v /var/lib/lxcfs/proc/swaps:/proc/swaps:ro \ -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:ro \ -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:ro \ -v /var/lib/lxcfs/proc/loadavg:/proc/loadavg:ro \ ubuntu:22.04 bash进去之后验证free -m # 应该显示约512MB而不是宿主机内存 nproc # 应该显示1而不是宿主机核数 uptime # 应该显示容器启动时长这里有几个必须注意的点。第一挂载必须加:ro否则容器内进程可能尝试写这些文件虽然lxcfs本身会拒绝但只读挂载更干净。第二--memory和--cpus必须在挂载之前或同时指定因为lxcfs读的就是cgroup限制值如果没设限制它读到的就是无限制显示的还是宿主机数值。第三/proc/cpuinfo的挂载在某些内核版本上会导致容器内lscpu行为异常如果业务依赖lscpu要单独测试。2.3 批量给所有容器挂载lxcfs的两种做法手动一个个加-v不现实。生产上我见过两种做法。第一种是改Docker daemon配置在/etc/docker/daemon.json里加默认挂载。但Docker原生不支持默认bind mount所以这条路走不通得靠编排层。第二种是在编排层统一注入。如果用docker-compose可以在每个service里写volumes如果用Kubernetes做法完全不同——K8s里通常用lxcfs的DaemonSet方案把宿主机的lxcfs挂载点通过hostPath暴露再用admission webhook自动注入volumeMounts。K8s场景下lxcfs的挂载路径和Docker不同需要把/var/lib/lxcfs/proc/meminfo挂到容器的/proc/meminfo同时要注意mountPropagation的设置否则挂载不会传播。我个人的经验是如果容器数量少、变动不频繁手动挂载最可控如果规模大一定要上自动化注入否则迟早有容器漏挂而漏挂的容器就是信息泄露的口子。漏挂这件事很隐蔽因为容器照常运行只是free显示错了没人会主动去查。2.4 lxcfs的边界与常见误判必须强调lxcfs的几个边界避免过度期待。它不隔离/sys。容器里/sys/fs/cgroup、/sys/devices这些路径仍然可能暴露宿主机信息尤其是没开user namespace的情况下。要处理/sys得靠其他手段比如只读挂载、masked paths。它不改变实际资源限制。lxcfs只是显示层真正限制内存CPU的还是cgroup。有人以为装了lxcfs容器就被限制了这是把显示和限制搞混了。它对/proc/self下的文件不生效。/proc/self/status、/proc/self/cgroup这些是进程自己的lxcfs不碰。攻击者仍然可以通过/proc/self/cgroup判断自己在容器里。所以lxcfs降低的是宿主机规格侦察的难度不是是否在容器中的判断。还有一个实测中的坑某些程序会缓存/proc/meminfo的读取结果。比如JVM在启动时读一次内存来决定堆大小之后不再读。这种情况下lxcfs必须在JVM启动前就挂好否则JVM已经按宿主机内存算好了堆大小后面再挂也没用。所以挂载时机要早于业务进程启动。3. 特权容器什么时候真的需要怎么把口子收窄3.1 特权容器到底开了什么--privileged这个参数很多人知道危险但说不清具体危险在哪。它的实际效果是给容器几乎所有的Linux capabilities关闭seccomp、AppArmor、SELinux的限制让容器内的root拥有和宿主机root几乎一样的能力。具体来说它做了这几件事赋予容器全部capabilities默认Docker只给一小部分关闭默认的seccomp profile关闭默认的AppArmor profile允许访问所有设备/dev下全部可见允许修改内核参数部分结果就是容器内root可以mount、可以mknod、可以加载内核模块如果宿主允许、可以访问宿主机磁盘设备。一个--privileged容器被攻破基本等于宿主机被攻破。3.2 用capabilities替代--privileged绝大多数需要特权的场景其实只需要一两个capability。我整理了一张对照表这是实际排查中最常用的需求需要的capability不要用--privileged修改网络配置NET_ADMIN是绑定低端口(1024)NET_BIND_SERVICE是修改文件属主CHOWN是绕过文件权限检查DAC_OVERRIDE是设置系统时间SYS_TIME是挂载文件系统SYS_ADMIN是这个要谨慎追踪进程SYS_PTRACE是原始IOSYS_RAWIO是用法docker run -it --rm \ --cap-dropALL \ --cap-addNET_ADMIN \ --cap-addNET_BIND_SERVICE \ nginx:alpine注意--cap-dropALL要放在--cap-add前面先把所有capability丢掉再按需加回来。这是最小权限原则的直接体现。我见过有人只写--cap-add不写--cap-dropALL结果容器仍然带着Docker默认的那一批capability等于没收敛。3.3 确实需要特权时的收窄手段有些场景确实绕不开特权比如某些需要操作块设备、需要SYS_ADMIN做mount的工具容器。这时候不要直接--privileged而是用组合手段把风险压到最低。第一用--device精确暴露设备而不是让容器看到所有设备docker run -it --rm \ --device/dev/sda:/dev/sda:rwm \ --cap-dropALL \ --cap-addSYS_RAWIO \ ubuntu:22.04--device只暴露指定设备比--privileged的全设备可见安全得多。第二叠加seccomp和AppArmor。即使加了capability也可以用自定义seccomp profile限制系统调用docker run -it --rm \ --security-opt seccomp/path/to/custom-seccomp.json \ --security-opt apparmormy-profile \ --cap-dropALL --cap-addSYS_ADMIN \ ubuntu:22.04第三用user namespace做映射。开启userns-remap后容器内的root映射到宿主机的一个非特权用户即使容器内root逃逸在宿主机上也只是普通用户。这个在/etc/docker/daemon.json里配{ userns-remap: default }改完重启Docker之后所有容器默认走userns映射。注意这会导致挂载卷的属主变化已有数据卷需要处理权限这是启用userns-remap最常见的坑。第四只读根文件系统。特权容器如果根文件系统可写攻击者可以往里面塞东西。加--read-only再单独挂载需要写的目录docker run -it --rm \ --read-only \ --tmpfs /tmp \ --tmpfs /run \ --cap-dropALL --cap-addSYS_ADMIN \ ubuntu:22.043.4 特权容器的审计与监控收窄是一方面监控是另一方面。我建议对所有带--privileged或带高危capability的容器做标记定期审计。可以用Docker的labeldocker run -it --rm \ --label security.privilegedtrue \ --label security.ownerteam-x \ --privileged \ ubuntu:22.04然后定期跑脚本列出所有带这个label的容器人工复核是否仍然需要。我见过太多临时开的特权容器最后变成永久运行没人记得为什么开的。审计的价值就在于逼着团队回答这个特权还需要吗。4. 容器白名单从能跑就行到只跑该跑的4.1 白名单的三个层次容器白名单这个词有点模糊实际落地时它至少分三个层次每个层次解决不同问题。镜像白名单只允许从指定仓库拉取指定镜像。防止有人从公网拉个来路不明的镜像就跑。落地方式是在私有registry前面做准入或者用镜像签名验证如cosign。进程白名单容器内只允许运行指定的可执行文件。防止攻击者上传工具、执行shell。落地方式是seccomp 只读根文件系统 最小化镜像。系统调用白名单只允许容器发起指定的系统调用。这是最底层的白名单用seccomp实现。三个层次里系统调用白名单最硬核也最有效但配置成本最高。我一般建议从镜像白名单做起再逐步往进程和系统调用收。4.2 用seccomp做系统调用白名单Docker默认的seccomp profile已经禁掉了一批危险系统调用但它是黑名单思路——默认允许禁掉已知危险的。更严格的做法是白名单——默认拒绝只允许业务真正需要的。写一个白名单profile结构是这样的{ defaultAction: SCMP_ACT_ERRNO, architectures: [SCMP_ARCH_X86_64], syscalls: [ { names: [ read, write, open, close, stat, fstat, mmap, mprotect, munmap, brk, exit, exit_group, rt_sigaction, rt_sigprocmask, rt_sigreturn, ioctl, access, pipe, select, sched_yield, clone, execve, wait4, kill, uname, fcntl, getdents, getcwd, readlink, gettimeofday, getpid, getuid, getgid, arch_prctl, futex, set_tid_address, set_robust_list, prlimit64, getrandom ], action: SCMP_ACT_ALLOW } ] }defaultAction设为SCMP_ACT_ERRNO意思是没在列表里的系统调用一律返回错误。然后只把业务需要的系统调用列进去。这个列表怎么来最实用的办法是先用默认profile跑业务用strace或auditd记录实际用到的系统调用再据此生成白名单。不要凭想象写一定会漏。生成之后这样用docker run -it --rm \ --security-opt seccomp/path/to/whitelist.json \ myapp:latest这里有个实测经验白名单profile对glibc版本很敏感。同一个程序在不同基础镜像上跑用到的系统调用可能不同。所以白名单要针对具体镜像测试不能跨镜像复用。我踩过一次坑一个profile在alpine上跑得好好的换到ubuntu基础镜像就起不来因为glibc启动时多调了几个系统调用。4.3 进程白名单与只读根文件系统系统调用白名单管的是能做什么动作进程白名单管的是能跑什么程序。后者靠组合手段实现。第一最小化镜像。用distroless或scratch基础镜像里面没有shell、没有包管理器、没有常用工具。攻击者即使拿到执行权限也没有东西可执行。这是最省事的进程白名单——不是禁止执行而是没得执行。第二只读根文件系统。--read-only让容器无法往根文件系统写任何东西攻击者无法上传工具。需要写的目录用tmpfs或单独挂载docker run -it --rm \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size64m \ --tmpfs /run:rw,noexec,nosuid,size16m \ myapp:latest注意noexec选项它让/tmp下的文件无法被执行进一步堵住上传到tmp再执行的路子。第三用AppArmor限制文件访问。AppArmor profile可以精确到这个进程只能读这些路径、写这些路径。写profile比较繁琐但一旦写好约束力很强。一个简化的例子#include tunables/global profile myapp flags(attach_disconnected) { #include abstractions/base /app/** r, /tmp/** rw, /etc/ssl/certs/** r, deny /bin/** x, deny /usr/bin/** x, deny /proc/*/mem rw, }这个profile允许读/app、读写/tmp、读证书但禁止执行/bin和/usr/bin下的任何东西禁止读写其他进程的内存。用--security-opt apparmormyapp加载。4.4 白名单的维护成本与取舍白名单最大的问题不是技术是维护成本。业务一升级可能引入新的系统调用或新的可执行文件白名单没更新容器就起不来。生产环境里白名单太严会导致频繁故障太松又失去意义。我的取舍原则是核心业务、对外暴露的服务白名单要严内部工具、临时任务白名单可以松但要有审计。不要一刀切。另外白名单的更新要走和代码一样的流程——版本控制、review、灰度。我见过白名单直接在生产机器上手改改完没记录下次出问题根本不知道谁改的。5. 一套可落地的容器安全加固思路5.1 加固的优先级排序安全加固最怕的是什么都想做结果什么都没做透。我按投入产出比排了个序从高到低不用特权容器用capability替代。改动小收益大直接砍掉最大的一类风险。镜像来源管控。只从可信仓库拉镜像禁止latest标签用digest固定版本。只读根文件系统 tmpfs。一行参数的事堵住大量写入型攻击。lxcfs信息隔离。部署一次所有容器受益降低侦察面。seccomp白名单。成本高但对高价值目标值得做。AppArmor/SELinux。成本最高适合合规要求严格的场景。这个排序的意思是先把1到4做完再考虑5和6。很多团队一上来就研究seccomp白名单结果特权容器满地跑本末倒置。5.2 一份完整的加固启动参数模板把前面的手段组合起来我给一个可以直接抄的模板docker run -d \ --name myapp \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size64m \ --tmpfs /run:rw,noexec,nosuid,size16m \ --cap-dropALL \ --cap-addNET_BIND_SERVICE \ --security-opt no-new-privileges \ --security-opt seccomp/etc/docker/seccomp/myapp.json \ --security-opt apparmormyapp \ --memory512m \ --cpus1 \ --pids-limit100 \ -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:ro \ -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:ro \ -v /var/lib/lxcfs/proc/stat:/proc/stat:ro \ -v /var/lib/lxcfs/proc/uptime:/proc/uptime:ro \ --user 1000:1000 \ myapp:1.2.3逐个解释关键参数--read-only根文件系统只读--tmpfs需要写的目录用内存盘noexec禁止执行--cap-dropALL先丢光所有capability--cap-addNET_BIND_SERVICE只加回绑定低端口这一个--security-opt no-new-privileges禁止进程通过setuid提权--security-opt seccomp...加载自定义系统调用白名单--security-opt apparmor...加载文件访问约束--memory/--cpus资源限制也是lxcfs的数据来源--pids-limit限制进程数防fork炸弹--user 1000:1000以非root用户运行lxcfs挂载信息隔离这一套下来容器的攻击面比默认配置小了一个数量级。但要注意不是所有应用都能直接套这个模板。比如需要写日志到文件的应用--read-only会导致写失败得把日志目录单独挂载。所以模板是起点不是终点要按业务调整。5.3 加固后的验证清单配完不是就完了要验证。我每次加固后都会跑一遍这个清单检查项验证命令期望结果内存视图docker exec 容器 free -m显示容器限制值CPU视图docker exec 容器 nproc显示容器配额根文件系统只读docker exec 容器 touch /test报Read-only file systemcapability收敛docker exec 容器 capsh --print只有指定的capability非root运行docker exec 容器 iduid不是0提权禁止docker exec 容器 su -失败进程数限制容器内跑fork循环达到pids-limit后失败这个清单我建议做成脚本每次发布新镜像或改配置后自动跑。加固配置最容易在迭代中悄悄退化——某次为了排查问题临时加了--privileged问题解决后忘了删就一直留着了。自动化验证能抓住这类退化。5.4 几个反复踩到的坑最后分享几个我在实操中反复遇到的问题都是文档里不会写的。坑一lxcfs和--read-only的冲突。lxcfs挂载点是bind mount和--read-only不冲突但如果容器内进程尝试写/proc/meminfo会因为只读挂载失败。这本身是好事但有些程序启动时会尝试写/proc/sys下的参数--read-only会让它启动失败。解决办法是把需要写的/proc/sys子路径单独用tmpfs覆盖或者用--sysctl在启动时设好。坑二seccomp白名单和JIT的冲突。JVM、.NET这类带JIT的运行时会动态生成代码需要mprotect带PROT_EXEC如果白名单里mprotect的参数没放开JIT会失败。这类运行时的白名单要特别测试不能照搬C程序的白名单。坑三userns-remap和已有数据卷的权限。开启userns-remap后容器内uid 0映射到宿主机uid 100000之前用root写的数据卷容器内非root用户读不了。迁移时要批量改属主chown -R 100000:100000。这个操作在数据量大时很慢要提前规划停机窗口。坑四capability加了但没生效。有些capability需要内核支持或者被上层策略覆盖。比如加了SYS_TIME但宿主机禁了时间修改容器内还是改不了。排查时先确认宿主机层面允许再看容器配置。坑五白名单更新导致滚动发布失败。K8s滚动发布时新Pod用新白名单旧Pod用旧白名单如果新白名单有问题新Pod起不来滚动卡住。所以白名单变更要单独灰度不要和业务发布绑在一起。这些坑的共同点是它们都不会在配置阶段暴露只在运行时暴露而且往往在压力或特定路径下才触发。所以加固配置一定要在预发环境充分测试不要直接上生产。我自己现在的习惯是任何安全配置变更先在预发跑至少一个完整的业务周期包括高峰和低谷确认没问题再推生产。
