尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
k8s漏洞学习
一、K8s简介kubernetes(简称k8s)是一个容器编排平台,可自动管理成千上万个“装着小程序的盒子(容器)”-什么时候启动、放在哪台机器上启动、挂了怎么重启、怎么互相访问.类比:容器:类似于集装箱,里面装着程序代码,可以搬到任何“码头”(操作系统)的地方运行kubernetes:类似于港口调度中心,负责决定每个集装箱放哪艘船、什么时候卸货、哪艘船坏了怎么把货转移走.k8s是企业的“数字神经中枢”,集群里跑着所有业务.一旦攻破等于拿到整个公司的核心资产。而且 K8s 组件多、配置复杂默认配置往往是能用但不够安全这就是漏洞的温床。二、k8s架构描述┌────────────────────────────────────────────┐ │ 控制平面 (Control Plane) │ │ │ kubectl/用户 ──► │ ┌─────────────────────────────────────┐ │ │ │ kube-apiserver (6443) │ │ │ │ 认证 → 鉴权 → 准入 → 写入 │ │ │ └───┬──────────────┬──────────────┬───┘ │ │ │ │ │ │ │ ┌───▼─────┐ ┌────▼─────┐ ┌────▼───┐ │ │ │ etcd │ │scheduler │ │controller│ │ │ │(2379) │ │ │ │ manager │ │ │ └─────────┘ └──────────┘ └──────────┘ │ └────────────────────────────────────────────┘ │ HTTPS (watch/指令) ▼ ┌─────────────────────────────────────────────────────────────┐ │ 工作节点 (Worker Nodes) │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌─────────┐ │ │ │ kubelet │◄────►│ kube-proxy │ │ CNI │ │ │ │ (10250) │ │ (iptables/ │ │ (Calico │ │ │ │ │ │ IPVS) │ │ 等) │ │ │ └──────┬───────┘ └──────────────┘ └─────────┘ │ │ │ CRI 接口 │ │ ┌──────▼───────────────────────────────────────────────┐ │ │ │ 容器运行时 (containerd / CRI-O) │ │ │ │ │ │ │ │ ┌────────────────────────────────────────────┐ │ │ │ │ │ Pod (最小调度单元) │ │ │ │ │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │ │ │ │ │ │ 容器 A │ │ 容器 B │ │ 容器 C │ (pause沙箱)│ │ │ │ │ │ └───────┘ └───────┘ └───────┘ │ │ │ │ │ └────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ CoreDNS、Metrics Server、Ingress Controller 等附加组件同样以 Pod 形式跑在节点上1. 控制平面Control Plane—— 集群的大脑控制平面负责决策与状态管理是集群的大脑kube-apiserverAPI 服务器集群的唯一入口。所有请求来自 kubectl、各组件、Pod 内的 Token都必须经过它依次经过认证 → 鉴权 → 准入控制三道关卡后才写入 etcd。它是唯一能与 etcd 通信的组件。etcd基于 Raft 共识的分布式一致性键值库保存集群全部状态节点、Pod、ConfigMap、Secret、ServiceAccount Token 等。etcd 里存的秘密就是整个集群的命根子。kube-scheduler调度器监听尚未调度的新 Pod综合节点资源、亲和性、污点容忍、数据本地性等因素选出最合适的节点并把结果写回 API Server它只做决策不执行。kube-controller-manager控制器管理器一堆控制器的集合体每个控制器各自维护期望状态 实际状态。例如 Deployment 控制器负责滚动更新、ReplicaSet 控制器负责副本数、ServiceAccount 控制器负责创建 Token。任何偏差它都会试图纠正。2. 工作节点Worker Nodes—— 集群的四肢工作节点负责真正跑应用是干活的地方kubelet节点代理每台节点上的常驻管家。它通过 HTTPS 主动连接 API Serverwatch 分派给自己节点的 Pod 清单然后通过CRI接口命令容器运行时创建/删除容器并持续上报节点与 Pod 状态、执行探针检查。容器运行时Container Runtime真正开箱子的程序如containerd、CRI-O。它按 CRI 标准接收 kubelet 指令管理容器的完整生命周期。kube-proxy网络代理为 Service 生成iptables/IPVS 规则实现集群内外的流量转发与负载均衡让访问 Service 的请求能落到后面的 Pod 上。CNI 网络插件补充你遗漏的关键组件如 Calico、Cilium、Flannel。负责给每个 Pod 分配 IP、打通 Pod 之间的网络并提供 NetworkPolicy 隔离能力。3. 附加组件Addons—— 可选但常用的外挂CoreDNS集群内域名解析让 Pod 之间用服务名互相访问。Metrics Server采集节点与 Pod 的 CPU/内存指标供 HPA 自动伸缩和kubectl top使用。Dashboard网页管理界面默认不安装装了必须配好鉴权。Ingress Controller如 NGINX Ingress把外部 HTTP(S) 流量按域名/路径路由到集群内部 Service。三、k8s组件先认识再找漏洞组件通俗解释默认端口/位置kube-apiserver唯一门卫翻译官所有命令都必须经过它6443 (HTTPS), 8080 (老版本明文)etcd账本存集群全部配置和密码2379/2380kube-scheduler房产中介决定新 Pod 放哪台机器10251kube-controller-manager监工确保集群状态符合预期10252cloud-controller-manager对接云厂商的翻译10257kube-proxy每台机器上的快递员负责转发流量10249容器运行时真正开箱子的如 containerd、CRI-O随版本变化CoreDNS集群内电话簿域名解析53Dashboard网页版管理界面经常被攻击自己暴露的端口CNI 网络插件Calico / Flannel / Cilium / Weave每个 Pod 的身份证道路负责给每个 Pod 分配独立 IP、打通 Pod 与 Pod / Service 之间的网络、实现 NetworkPolicy 隔离以 DaemonSet 形式跑在每个节点上端口因插件而异Calico 常监听 179/BGP 等Ingress ControllerNGINX Ingress / Traefik 等集群的前台接待把外部 HTTP(S) 请求按域名/路径路由到内部 Service自己暴露的 80/443或 NodePort/LoadBalancerMetrics Server集群的体重秤采集节点和 Pod 的 CPU/内存指标支撑kubectl top和自动伸缩HPAkubelet 上的聚合端口通过 API Server 6443 代理访问pause 沙箱容器Infra Container每个 Pod 里的透明小管家单独持有网络命名空间让 Pod 内所有容器共享网络你docker ps看 K8s 节点时看到的那些看不见进程的容器就是它kubelet 先拉起它才拉业务容器kubeadm / kubelet / kubectl安装三件套集群的施工队kubeadm 是初始化集群的工具不是运行时组件但很多教程把它混进来kubelet每台机器上的管家执行 API Server 的指令10250 (HTTPS), 10255 (只读)kubectl客户端工具你手里的遥控器严格说不算集群组件但它是唯一入口~/.kube/config泄露 集群沦陷安全重点容器运行时接口 CRICRI-O / containerd 的 API运行时和 kubelet 之间的普通话标准不是组件而是协议但了解它才能理解为什么 Docker 从 1.24 起被移出核心四、真实工作场景补一个真实工作场景串联把架构讲活这一节是优化重点——把静态架构变成动态流程。以部署一个 Nginx 应用为例看组件如何协同Step 1你执行kubectl create deployment nginx --imagenginx→ kubectl 读取本地配置用 HTTPS 把请求发给kube-apiserver。Step 2API Server 依次执行认证你的证书/Token 是谁→鉴权你是否有创建 Deployment 的权限→准入控制资源配额、安全策略检查通过后把 Deployment 对象写入 etcd。Step 3kube-controller-manager里的 Deployment 控制器 watch 到新对象 → 创建 ReplicaSet → ReplicaSet 控制器创建 Pod 对象此时 Pod 处于Pending还没分配节点。Step 4kube-scheduler监听到未调度的 Pod → 综合各节点资源情况选出最合适的节点→ 把绑定信息写回 API Server。Step 5目标节点上的kubeletwatch 到有一个 Pod 分给我了 → 通过CRI接口让containerd拉取 nginx 镜像并启动容器同时拉起 pause 沙箱容器→CNI 插件给 Pod 分配 IP 并打通网络。Step 6kubelet 持续上报状态给 API Server写入 etcd并定期执行探针检查 nginx 是否存活。如果容器挂了kubelet 按重启策略拉起如果节点挂了控制器在其他节点重建 Pod。Step 7你想让外部访问它创建 Service →kube-proxy在节点上写入 iptables/IPVS 规则 → 流量被内核转发到 Pod。再配一个Ingress域名请求就被 Ingress Controller 路由进来。这个流程里的每一步都是一个安全攻击面Step 2 的认证鉴权可绕过、Step 3-4 可被恶意调度/污点利用、Step 5 的容器运行时和镜像可被攻击、Step 6 的 kubelet 端口可被匿名访问、Step 7 的 Service/Ingress 可被劫持五、漏洞风险点分析重点按攻击者视角从外到内、从上到下分层拆解。每一层我都会说清楚漏洞是什么、怎么被利用、怎么防护。第一层API Server 层最值钱的目标风险点 1匿名访问anonymous authK8s 默认允许匿名用户访问如果管理员把匿名用户绑定到了高权限 Role/ClusterRole比如system:anonymous绑定了cluster-admin任何人都能kubectl直接控制集群。利用方式直接访问https://master:6443/api看看返回什么。如果返回资源列表而不是 401就中奖了。风险点 2--insecure-port与--insecure-bind-address老版本 K8s 默认开了 8080 明文端口没有任何认证直接访问就能执行操作。利用方式curl http://master:8080/api/v1/pods或直接kubectl -s http://master:8080 get pods。风险点 3kubectl 证书/Token 泄露管理员把~/.kube/config里面是管理员证书传到 GitHub、网盘、或者被钓鱼窃取 → 攻击者直接获得完整集群权限。Service Account Token 如果被注入到恶意容器也能以该 SA 的身份调用 API。风险点 4RBAC 配置错误给普通用户/命名空间绑了过大的权限如给了cluster-admin、*通配符权限。比如某些 CI/CD 系统的 SA 被授予了pods/exec权限 → 等于可以进入任意容器。风险点 5历史上著名的 API Server 漏洞CVE-2018-1002105kube-apiserver 升级连接upgrade request处理不当任何能访问 API 的用户包括低权限都能通过kubectl exec在节点上以 root 执行命令。CVE-2020-8558NodePort 服务默认--service-node-port-range相关部分流量可绕过网络策略。CVE-2022-3172kube-apiserver 聚合层等。第二层etcd 层账本被偷 全盘皆输etcd 存着集群所有秘密Service Account Token、证书、配置、密码。etcd 沦陷 拿到整个集群的万能钥匙。风险点 1端口暴露到公网etcd 默认监听 2379如果没做防火墙限制公网直接可连。利用方式etcdctl --endpointshttp://target:2379 get / --prefix直接 dump 全部数据从中提取管理员的 Token 和证书。风险点 2没有启用 TLS 客户端证书认证明文通信局域网内可被嗅探MITM。老版本默认甚至不校验客户端身份任何人能读写。风险点 3备份文件泄露etcd 快照snapshot文件如果被放到不安全位置同样等于拿到全部秘密。实战口诀先打 API Server打不动就打 etcdetcd 打了基本就赢了。第三层kubelet 层每台机器上的管家也能被收买风险点 110250 端口匿名可访问最经典的 kubelet 漏洞老版本 kubelet 的 10250 端口默认不校验身份或只校验很弱的凭证。利用方式bash复制# 直接列出节点上的 Pod curl -k https://node:10250/pods # 在容器里执行命令如果开了 exec 权限 curl -k -XPOST https://node:10250/run/namespace/pod/container -d cmdid风险点 210255 只读端口泄露信息10255 是只读端口虽然不能执行命令但能泄露大量运行信息环境变量、挂载信息辅助后续攻击。风险点 3kubelet 配置错误--anonymous-authtrue默认允许匿名--authorization-modeAlwaysAllow老版本默认任何请求都放行第四层容器与 Pod 层横向移动 逃逸就算进了容器目标通常是逃出容器拿到宿主机/节点权限。风险点 1特权容器privileged: true拥有宿主机几乎全部权限逃逸极其简单。利用方式经典逃逸bash复制# 在特权容器内 mkdir /mnt/host mount /dev/sda1 /mnt/host chroot /mnt/host # 或利用 cgroup release_agent 逃逸风险点 2共享命名空间hostPID: true、hostNetwork: true、hostIPC: true→ 容器能看到宿主机进程/网络可直接 ptrace 注入或扫描内网。风险点 3危险 Capabilities容器被授予了SYS_ADMIN、NET_ADMIN、CAP_SYS_PTRACE等能力 → 逃逸门槛大大降低。检查方式容器内capsh --print查看。风险点 4内核漏洞逃逸最热门容器共享宿主机内核内核有洞 容器逃逸。著名案例CVE-2022-0185Linux 内核堆溢出fs.context 相关、CVE-2021-22555Netfilter、CVE-2020-14386内核 AF_PACKET等。还有CVE-2023-5528runC 泄漏文件描述符导致逃逸、CVE-2024-21626runC/containerd Leaky Vessels 系列恶意镜像可通过/proc/self/fd逃逸这是 2024 年非常热门的一族。风险点 5Service Account Token 滥用每个 Pod 默认自动挂载一个 SA Token 到/var/run/secrets/kubernetes.io/serviceaccount/token。如果这个 SA 权限过大容器被攻破后攻击者直接用它调 API Server 横向移动。第五层网络层横向移动的通道风险点 1Service Account Token 可访问云元数据服务SSRF 经典打法集群在云上时攻击者可以从 Pod 访问169.254.169.254AWS 元数据或100.100.100.200阿里云拿到云凭证AK/SK直接接管云账号。配合任意 SSRF 漏洞非常致命。风险点 2集群内网无隔离没有配置 NetworkPolicyPod 之间全互通 → 攻破一个 Pod 就能扫整个内网。风险点 3CVE-2020-8554Man in the middle using LoadBalancer任何能创建 Service 的用户可以把 Service 的 externalIP 设为任意 IP包括网关、kube-apiserver从而劫持集群内所有流量。风险点 4DNS 投毒 / CoreDNS 配置错误恶意 Pod 伪装成服务名诱导其他服务连过来名字相似攻击。第六层附加组件层攻击面最容易被忽略风险点 1Kubernetes Dashboard经典打法--enable-skip-login开启 匿名访问 → 直接进管理面板 → 在里面创建特权 Pod → 逃逸。很多教程让你开 Dashboard 但没配 RBAC导致任何能访问 Dashboard 的人 cluster-admin。风险点 2Ingress Controller / API 网关历史上CVE-2021-25742、CVE-2021-25743NGINX Ingress可通过注入 annotation 在 nginx 进程执行任意命令。Ingress 配置错误比如把内部服务暴露出去。风险点 3Helm / Tiller老版本 Helm 2 的 Tiller 默认监听 44134 且无认证任何人连上去就能部署恶意 chart。Helm chart 里的恶意模板供应链攻击。风险点 4监控组件Prometheus、GrafanaGrafana 未授权/弱口令 → 拿到数据 → 可能 SSRF → 打内网。六、完整攻击链示例第一阶段入口攻击者发现集群暴露的 Dashboard 或 API Server 未授权│第二阶段立足获得 API Server 访问权限或通过 SSRF/弱口令进入 Pod│第三阶段提权读取 Pod 内的 SA Token → 检查该 SA 的 RBAC 权限找到 pods/exec、secrets 读取等高权限│第四阶段横向移动通过 SA Token 创建特权 Pod / 或 exec 进入其他高价值 Pod访问云元数据服务拿云 AK/SK│第五阶段逃逸与持久化特权容器 内核漏洞 → 逃逸到宿主机修改 etcd / 植入后门 Pod / 篡改镜像仓库│最终全集群沦陷甚至云账号沦陷七、防护清单反向学习漏洞层面必做加固API Server禁用匿名访问、开启 RBAC、审计日志audit log、限制--insecure-portetcd防火墙只允许 API Server 访问、启用 TLS 双向认证、加密静态数据kubelet设置--anonymous-authfalse、--authorization-modeWebhook、10255 只监听本机容器禁止特权容器、限制 capabilities、开启 PodSecurity (PSA)、只读根文件系统网络启用 NetworkPolicy 默认拒绝、限制元数据服务访问如 metadata 代理、启用 TLS 加密凭证定期轮换证书/Token、最小权限原则、不用默认 Service Account镜像使用可信镜像仓库、镜像扫描trivy 等、验证签名运行及时升级 K8s多数 CVE 在新版修复、开启审计、部署 falco 等运行时检测八、安全学习衔接_关键端口速查组件端口用途安全关注点kube-apiserver6443HTTPS 主入口匿名访问、RBAC 错误、Token 泄露kube-apiserver (insecure)8080老版本明文端口无认证致命etcd2379/2380数据存储/集群通信公网暴露 全盘沦陷kubelet10250主端口HTTPS匿名可访问时可远程执行kubelet (read-only)10255只读信息泄露泄露环境变量、挂载信息kube-scheduler10251健康检查/指标一般本机即可kube-controller-manager10252健康检查/指标一般本机即可kube-proxy10249指标一般本机即可Dashboard自己暴露Web 管理界面未授权/弱口令集群沦陷九、推荐学习资源与实验环境官方安全文档Kubernetes 官方 Security 文档Pod Security Standards、RBAC 文档。实验环境Kubernetes Goat —— 专门练习 K8s 漏洞的靶场强烈推荐小白友好。kube-hunter —— 自动扫描集群漏洞的工具用来对照学习。本地用minikube / kind / k3s起一个测试集群慢慢折腾。中文资料CSA 发布的 《Kubernetes 安全指南》 以及 Wiz 的 Kubernetes 架构安全分析 和 集群安全审查都是很好的进阶读物。漏洞库关注 Kubernetes 官方 CVE 列表、OSV.devGo 生态漏洞库K8s 相关 CVE 都收录其中。十、总结回顾全文主线其实很清晰先懂架构再找攻击面最后落到防护。K8s 的架构决定了它的安全边界——kube-apiserver 是唯一入口etcd 是全部秘密的账本kubelet 是每台节点上的管家容器与 Pod 是真正跑业务的地方网络是横向移动的通道附加组件则是最容易被忽略的外挂。攻击者正是沿着这条链路从 API Server 未授权、etcd 暴露、kubelet 匿名访问一路走到特权容器逃逸、云元数据窃取和 Dashboard 沦陷。反过来看防护清单里的每一条加固其实都对应着一个具体的攻击面禁用匿名访问、启用 RBAC 与审计、限制特权容器与 Capabilities、开启 NetworkPolicy 默认拒绝、及时升级修复 CVE。理解了为什么会被打才知道该怎么防。给初学者的三条行动建议先搭靶场用 minikube / kind / k3s 起一个本地集群再配合 Kubernetes Goat 亲手复现一遍未授权访问、特权容器逃逸等场景比只看文章印象深得多。再按防护清单自查对照第七节的表格逐项检查自己的集群从 API Server、etcd、kubelet 到容器、网络、凭证把能用的默认配置改成够安全的配置。最后关注 CVE 公告K8s 及周边组件漏洞更新很快养成订阅官方 CVE 列表、OSV.dev 等渠道的习惯及时评估影响并升级版本。
RELATED

相关推荐

Tcl语言:info命令的使用方式

Tcl语言:info命令的使用方式

Tcl语言https://blog.csdn.net/weixin_45791458/category_12488978.html?spm1001.2014.3001.5482 info命令是Tcl中非常重要的信息查询命令。它主要用于查询解释器状态、变量信息、命令信息、过程信息、调用栈信息等内容。 在Tcl脚本调试、过程封装、变量检查以及EDA工具脚本开…

📅 2026/10/26 10:00:54
炉石传说 HsMod 完整加速指南:8 倍速战斗、帧率锁定与挂机自动化,10 分钟完成调优

炉石传说 HsMod 完整加速指南:8 倍速战斗、帧率锁定与挂机自动化,10 分钟完成调优

炉石传说 HsMod 完整加速指南:8 倍速战斗、帧率锁定与挂机自动化,10 分钟完成调优 【免费下载链接】HsMod Hearthstone Modification Based on BepInEx 项目地址: https://gitcode.com/GitHub_Trending/hs/HsMod 动画拖沓、弹窗打断、开包领奖全靠…

📅 2026/10/26 10:00:54
MediaCrawler-new 多平台数据采集教程:5 分钟从零跑通小红书、抖音爬虫

MediaCrawler-new 多平台数据采集教程:5 分钟从零跑通小红书、抖音爬虫

MediaCrawler-new 多平台数据采集教程:5 分钟从零跑通小红书、抖音爬虫 【免费下载链接】MediaCrawler-new 项目地址: https://gitcode.com/GitHub_Trending/me/MediaCrawler-new MediaCrawler-new 是一个开源的社交媒体数据采集框架,覆盖小红书…

📅 2026/10/26 10:00:54
MORE NEWS

更多资讯

📰

亿级流量系统架构设计:高并发挑战与解决方案

1. 亿级流量系统的挑战与设计哲学 当系统流量突破亿级大关时,传统的架构设计思路会遭遇前所未有的挑战。我在参与某电商大促系统改造时,曾亲眼见证QPS从5万暴涨到120万的瞬间,这让我深刻理解了阿里技术团队提出的"稳定压倒一切"的设…

📰

100kW导热油炉工业应用与控制系统详解

1. 项目概述:100kW导热油炉的工业应用场景 100kW瑞源电加热导热油炉是工业生产中常见的中小型热源设备,主要应用于需要精确控温的工艺环节。这类设备在塑料成型、化工反应、食品烘干等行业中扮演着关键角色,其核心优势在于能够提供稳定的高温…

📰

Vivado+Verilog单周期CPU设计:MIPS数据通路与上板调试

简介:面向计算机组成原理课程设计与FPGA入门学习者的单周期CPU工程,用Verilog在Vivado中实现取指、译码、执行、写回的数据通路,涵盖指令寄存器、译码器、ALU、通用寄存器组、控制单元、存储器接口与程序计数器等模块,可帮助理解控…

📰

UR5机械臂MATLAB轨迹规划:DH建模、插补与奇异避坑

简介:这份资料围绕UR5六轴机械臂在MATLAB环境下的轨迹规划展开,面向机器人工程、自动化控制方向的学习者与实验开发者,侧重解决从运动学、动力学建模到平滑路径生成的完整实践问题。内容涉及正逆运动学求解、雅可比计算、欧拉角变换、关节空间…

📰

Linux HISTFILE环境变量详解与实用技巧

1. HISTFILE 是什么? 在 Linux/Unix 系统中,HISTFILE 是一个非常重要的环境变量,它决定了 shell 历史命令记录文件的存储位置。简单来说,这个文件就像是你终端操作的"黑匣子",忠实地记录着你输入过的每一条命…

📰

云服务器部署Dify:AI应用开发平台搭建指南

1. 为什么选择云服务器部署Dify? 在当今AI技术快速发展的时代,越来越多的开发者希望搭建自己的AI应用平台。Dify作为一个开源的AI应用开发平台,能够帮助开发者快速构建和部署AI应用。而云服务器因其弹性、可靠和易管理的特点,成为…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬