容器与云原生主机安全防护架构怎么搭：实战落地指南

核心要点（TL;DR）

容器共享宿主机内核，主机层防护是容器安全的最后一道防线。
节点加固优先做：关闭多余服务、限制kubelet匿名访问、启用CIS基线。
运行时安全用eBPF或审计日志监控逃逸与异常进程，比签名更有效。
镜像扫描加最小权限与网络策略，可显著缩小横向移动面。

很多团队上了 Kubernetes 后，把安全预算全押在镜像扫描和 RBAC 上，却忽略了节点本身：宿主机 SSH 弱口令、kubelet 匿名访问开放、特权容器满天飞。容器与宿主机共享内核，一旦节点被拿下，整个集群都可能沦陷。本文面向要动手落地的运维与站长，给出容器与云原生环境下主机安全防护架构的分层搭建方法与可执行命令。

一、先搞清楚：云原生主机安全的攻击面在哪

与传统物理机不同，云原生节点的风险集中在四类入口：

控制面组件暴露：kubelet 10250/10255、etcd 2379 未授权访问。
容器逃逸：privileged 容器、挂载 docker.sock、hostPath 挂载宿主机根目录。
内核与运行时漏洞：共享内核意味着一个 CVE 影响所有 Pod。
凭据泄露：ServiceAccount Token、云厂商 metadata 接口被滥用。

防护架构要围绕“节点加固—最小权限—运行时监控—网络隔离”四层展开，缺一层都会留下横向移动通道。

二、第一层：节点基线加固（可立即执行）

先做操作系统与 kubelet 的基线收敛，这是性价比最高的一步。

# 1. 关闭 kubelet 匿名访问（/var/lib/kubelet/config.yaml）
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
authorization:
  mode: Webhook

# 2. 验证是否生效，返回 401/403 即正确
curl -k https://127.0.0.1:10250/healthz

# 3. 检查特权容器与 hostPath 挂载
kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.name'

# 4. 使用 kube-bench 跑 CIS 基线
kube-bench run --targets node,master

同时关闭节点上无关服务（telnet、rpcbind）、限制 SSH 仅密钥登录、启用 auditd 记录 execve 与 mount 调用。建议把 kube-bench 结果纳入 CI，基线不达标不允许节点加入集群。

三、第二层：最小权限与隔离，堵住逃逸路径

逃逸大多源于“给多了”。落地时按以下清单逐项收敛：

风险项	加固做法
privileged 容器	禁止使用，改用细粒度 capabilities，如仅授予 NET_BIND_SERVICE
hostPath 挂载	用 PVC 替代，必须挂载时限定只读与具体路径
ServiceAccount	关闭 automountServiceAccountToken，按需绑定最小 Role
宿主机命名空间	禁止 hostPID、hostNetwork、hostIPC

配合 Pod Security Admission 设置 restricted 级别，并用 OPA Gatekeeper 或 Kyverno 做准入校验，把上述规则变成“不合规就拒绝创建”，而不是靠人工巡检。

四、第三层：运行时监控，抓逃逸与异常行为

签名和扫描只能防已知问题，运行时才是主战场。推荐基于 eBPF 采集进程、网络与文件事件，重点关注：

容器内执行 nsenter、mount、insmod 等敏感命令；
访问 /proc/1/root、/var/run/docker.sock；
反弹 shell 特征与异常外联；
容器内启动 sshd、cron 等常驻进程。

以 Falco 为例，部署后可用如下规则思路快速验证：监控 execve 中出现的逃逸工具，并输出到告警通道。对高负载节点，只保留提权、逃逸、反弹 shell 三类高价值规则，避免告警风暴。此处可结合 AegisX 的运行时采集与主机入侵检测能力，把节点与容器事件统一收敛到同一告警面，减少多套 agent 的运维成本。

五、第四层：镜像、网络与日志的闭环

最后一层是把入口和出口都管住：

镜像：CI 阶段扫描高危漏洞并阻断，仓库定期复扫，禁止 latest 标签。
网络：默认拒绝的 NetworkPolicy，仅放通必要端口；节点侧用安全组限制 10250、2379 只对控制面开放。
日志：开启 API Server 审计日志与节点 auditd，集中采集并设置保留期，便于事后溯源。

检查清单：kubelet 匿名访问已关闭、无特权容器、无 hostPath 根目录挂载、PSA 已启用、运行时告警已接入值班、镜像扫描已进 CI、NetworkPolicy 默认拒绝。七项全绿，架构才算闭环。

行动建议

不要一次铺开。第一周先关 kubelet 匿名访问并跑 kube-bench 出基线报告；第二周清理特权容器与 hostPath；第三周接入 eBPF 运行时告警并演练一次逃逸场景。每步都留验证命令与回滚方案，主机安全防护架构才能真正落地并持续运营。

常见问题（FAQ）

容器环境还需要做主机安全防护吗？

需要，而且更重要。容器与宿主机共享内核，一旦发生容器逃逸或内核提权，攻击者可直接控制节点并横向移动到整个集群。主机层应做基线加固、最小权限、运行时监控与日志审计，形成节点、容器、网络三层防护，不能只依赖镜像扫描。

kubelet 的匿名访问怎么关闭？

在 kubelet 配置中设置 authentication.anonymous.enabled 为 false，并开启 Webhook 授权模式，然后重启 kubelet。可用 curl -k https://节点IP:10250/healthz 验证，返回 401/403 即已生效。同时限制 10250、10255 端口只对控制面开放，避免未授权读取 Pod 信息或执行命令。

怎么检测容器逃逸行为？

重点监控宿主机上的异常进程与挂载行为：容器内出现 nsenter、mount 宿主机目录、访问 /proc/1/root、加载内核模块等。可用 eBPF 工具（如 Tetragon、Falco）采集 execve、mount、setns 事件并告警，同时开启 auditd 记录特权操作，定期核对特权容器清单。

镜像扫描应该放在哪个环节？

建议在 CI 构建阶段扫描并阻断高危漏洞，在镜像仓库做定期复扫，在集群准入阶段用 admission controller 校验签名与漏洞等级。三层配合可避免带病镜像上线；同时固定基础镜像版本、禁止 latest 标签，减少不可控变更。

主机安全 agent 会不会影响业务性能？

合理选型影响很小。优先选择基于 eBPF 的采集方案，避免全量文件扫描；将采集频率、规则范围按业务分级配置，先在测试节点灰度观察 CPU 与 IO。对高负载节点可只保留关键规则（提权、逃逸、反弹 shell），并设置告警抑制避免风暴。

资讯中心