Kubernetes环境下的DNS应急响应指南

kubectl edit configmap coredns -n kube-system

nsenter -t <PID> -n bash

Kubernetes环境下的DNS应急响应指南 背景与概述 容器化架构的普及使得攻击面增大，传统安全方法在Kubernetes动态环境中存在局限性。本文将以Docker作为基础，逐步过渡到Kubernetes业务环境下的应急响应，特别是针对DNS恶意请求的排查方法。 Docker网络基础 Docker网络模式 Docker有四种网络模式，通过启动容器时指定： | 网络模式 | 参数 | 说明 | |---------|------|------| | Bridge | --net=bridge | 默认模式，通过 -p 指定端口映射 | | None | --net=none | 容器有独立Network namespace但无网络设置 | | Host | --net=host | 容器和宿主机共享Network namespace | | Container | --net={id} | 容器和另一个容器共享Network namespace | Kubernetes中的Pod就是多个容器共享一个Network namespace的实现。 Network Namespace Network namespace(网络命名空间) 是Linux内核提供的一种网络隔离机制，它允许在同一台主机上创建多个独立的网络栈。 关键特性 ： 独立的网络栈：每个都有自己独立的网络接口、IP地址、路由表等 进程级隔离：进程只能访问所在Network namespace的网络资源 轻量级实现：仅依赖Linux内核特性，比传统虚拟机更轻量 Cgroups Cgroups(Control Groups)是Linux内核提供的资源管理机制，允许限制、隔离和监控一组进程对系统资源的使用。它是Docker容器、Kubernetes资源管理的核心技术之一。 各网络模式详解 Bridge模式 Docker会在主机上创建名为 docker0 的虚拟网桥 每个容器都有虚拟网卡 eth0 容器间可以通过 172.17.x.x 相互通信 逻辑上与VMware Workstation的桥接模式类似 None模式 容器只有 lo 回环网络，没有其他网卡 无法联网，外部也无法访问 封闭的网络能很好保证容器安全性 Host模式 容器与主机共享网络 映射端口可能会产生冲突 文件系统、进程等依然是隔离的 Container模式 多个容器之间共享网络 首先启动一个bridge网络的容器A 其他容器使用 --net={id} 连接到A中 Kubernetes核心概念 Pod 将多个容器打包一起运行的执行单元 通过Docker的container模式实现容器间网络共享 是Kubernetes集群中最小的执行单位 所有容器共享相同的资源和本地网络 Pod与docker-compose的对比： | 特性 | docker-compose | Kubernetes Pod | |------|---------------|----------------| | 作用范围 | 一组独立容器组成应用 | 最小单位，内部容器紧密协作 | | 网络 | 通过networks实现连接 | 共享同一IP，localhost直接通信 | | 存储 | volumes定义 | emptyDir、PersistentVolume | | 运行环境 | 容器各自运行 | 由Kubernetes管理 | | 扩展 | 手动scale | 自动扩展(HPA、Replicas) | Node Kubernetes中最小的计算硬件单元 可以是物理服务器或虚拟机 每个节点运行kubelet组件 分为master节点和worker节点 Kubernetes架构组件 API Server：集群核心，所有操作必经 Worker节点：运行Pod，使用kube-proxy处理网络通信 kubectl：命令行管理工具 proxy组件：确保集群内部服务流量正常转发 环境部署 Minikube Kubernetes的轻量级实现 提供本地开发和测试环境 在单一节点上运行完整Kubernetes集群 部署步骤： 启动minikube 通过 kubectl get nodes 验证部署 编写deployment.yaml和service.yaml 创建Deployment和Service 查看Pod和Service状态 DNS应急响应场景 场景描述 ： Kubernetes集群触发主机安全告警，显示某台主机尝试解析并访问已知恶意域名。排查发现被标记的主机实际承担了集群DNS解析功能(CoreDNS)，而非真正恶意流量发起者。 方法一：开启CoreDNS日志 CoreDNS介绍 Kubernetes默认DNS解析组件 解析Kubernetes服务和Pod的域名 代理集群外部DNS请求 提供负载均衡和缓存功能 CoreDNS架构 以Deployment形式运行 通过Service(kube-dns)供集群内Pod使用 解析流程 ： Pod内部的resolv.conf指向kube-dns service DNS查询请求发送到CoreDNS CoreDNS判断内部/外部域名 返回解析结果至请求Pod 开启日志配置 添加 log 指令后，Kubernetes会自动重启CoreDNS 排查步骤 在Pod中发起对恶意域名的请求 查看CoreDNS日志定位Pod IP 通过IP过滤定位对应Pod 方法二：使用nsenter抓包 适用于： 业务流量庞大的场景 容器缺少网络调试工具的情况 nsenter介绍 Linux命令行工具，用于进入另一个Namespace 可以进入任何类型的Linux Namespace 常用参数： | 参数 | 解释 | |------|------| | -n | 网络(Network Namespace) | | -p | 进程(PID Namespace) | | -m | 挂载(Mount Namespace) | | -u | UTS(主机名和域名Namespace) | | -i | IPC(进程间通信Namespace) | | -c | Cgroup(控制组Namespace) | | -U | 用户(User Namespace) | 排查步骤 在Pod宿主机(Node)上进入CoreDNS的namespace 使用tcpdump抓取53端口流量 同时在Pod向恶意域名发起请求 通过流量分析定位IP和Pod 总结 在Kubernetes环境下进行DNS应急响应时： 理解Docker和Kubernetes的网络基础是关键 CoreDNS是集群DNS解析的核心组件 两种主要排查方法： 开启CoreDNS日志（适合流量不大的场景） 使用nsenter抓包（适合生产环境） 掌握这些技术可以快速定位恶意请求来源Pod 通过本文介绍的方法，可以有效应对Kubernetes环境下的DNS安全事件，提高集群安全性。