海南建设工程股份有限公司网站,搜索风云排行榜,邯郸做网络推广的公司,和wordpress差不多呢问题背景
在云原生技术的广泛普及和实施过程中#xff0c;笔者接触到的很多用户需求里都涉及到对云原生集群的可观测性要求。 实现集群的可观测性#xff0c;是进行集群安全防护的前提条件 。而在可观测性的需求中#xff0c;集群中容器和容器之间网络流量的可观测性需求是…问题背景
在云原生技术的广泛普及和实施过程中笔者接触到的很多用户需求里都涉及到对云原生集群的可观测性要求。 实现集群的可观测性是进行集群安全防护的前提条件 。而在可观测性的需求中集群中容器和容器之间网络流量的可观测性需求是其中一个比较重要的部分。对于容器网络的流量采集其实施难度是大于传统主机网络的流量采集的。
那么容器网络的复杂度到底在哪里如何更好的去适配容器网络这里笔者结合在工作实践中的一些积累在本文中给出一些关于云原生集群网络流量可观测性的一点思考希望能起到抛砖引玉的效果。
CNI 插件
目前在 云隙自适应微隔离产品云原生场景适配 的过程中已经遇到过如下的一些 CNI 插件
Flannel —— 默认为 Vxlan 的分布式网关模式可选择 host-gw 模式也可以选择 udp 模式早已被淘汰的一种模式
Calico —— 默认的 BGP 模式使用 IPIP 隧道进行跨节点容器间数据的转发当然也可以不用 IPIP 隧道模式类似于 Flannel 的 host-gw 模式
Openshift-SDN —— 基于 Openvswitch 技术是一套基于 SDN 技术的网络方案
OVN-Kubernetes —— 基于 Openvswitch 中的 OVN 方案其实和 Openshift-SDN 是差不多类似的体系只是在架构和细节上做了更多的云原生优化
现有问题
上述几类插件是大多数云原生环境中常见的 CNI 插件并且它们本身也涵盖了容器间网络所使用的大部分技术。而在对以这几类 CNI 插件基础的容器网络进行流量信息采集的过程中笔者发现并不能用一种模式完成所有的采集功能。例如在有的 CNI 插件中我们需要把宿主机当作一个网络中转设备在主机上利用旁路的方式检测容器网络流量的变化情况而在有的 CNI 插件中我们没法在宿主机上直接观察到任何容器网络的流量信息需要进入到容器的网络命名空间中去完成采集工作甚至在有的 CNI 插件中我们无法抓到两个容器之间的直接访问关系必须要配合这个 CNI 插件本身实现的技术原理通过更多的分析来完成对访问关系的确定。
所以在进行容器网络流量的可观测性方案实施之前需要对相关 CNI 插件做进一步的分析来帮助理解为什么不同的 CNI 插件兼容适配的要求会有不同。
插件分析
Flannel 插件的原理
Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络Overlay NetworkCNI 插件。它可以配置为很多种工作模式目前默认的工作模式是 Vxlan是一个虚拟的二层网络。
组件概述 图1
Flannel 是以 DaemonSet 的方式部署在 Kubernetes 集群中。一个完整的 Flannel 架构中包含了如下的一些组件
etcd —— 这是 Flannel 所依赖的配置中心每个节点上的 flanneld 都会依赖这个 etcd 组件来实现协调和同步。在一般的部署方案中这个 etcd 是直接复用的 Kubernetes 控制层平面的 etcd 组件所以一般也没有单独部署。
flanneld —— 每一个宿主机节点之上都会启动一个 flanneld 服务目前默认是基于 Vxlan 的配置工作模式在这种模式和 host-gw 模式下flanneld 都主要承担了一个旁路配置管理的工作。而在 UDP 模式下flanneld 还要承担数据的转发工作由于该方案本身有严重的性能问题。所以早已被放弃不用。
网络模式概述
总的来说Flannel 是一个二层的网络解决方案。就其默认的 Vxlan 工作模式来说可以看作是应用 Vxlan 的分布式网关架构组建了一个二层的通信网络。在这种架构下宿主机中的虚拟网卡 flannel.1 可以看作是一个作为 Vxlan 二层网关和三层网关的 leaf 节点而宿主机本身的网卡则可以看作是用于转发的 spine 节点。
图2
在这种网络环境下跨界点的容器通信在接收端其实是无法直接抓到来自于发送端的 IP 地址的因为在三层转发的时候发送端的 IP 就已经被替换为了网关的地址。如果从旁路的角度来看宿主机上也无法直接观察到容器间流量。如果能观察到一般都是节点自身两个容器之间的连接因为它们本身处于一个二层网络中。同时在这种环境中如果使用 SideCar 模式去容器网络命名空间下进行观测也会发现由于这个虚拟二层网络本身存在三层转发的网关我们依然无法直接采集到两个容器之间的连接关系。
如果是 host-gw 模式那么宿主机就会被纯粹配置一个三层转发的网关虽然不走 Vxlan 这样的隧道了但是由于三层转发的存在我们依然无法直接观测到跨节点容器通信的网络关系。
综上所述在观测基于 Flannel 的网络流量之时一定要结合 Flannel 的架构本身将三层网关的转发特性考虑到网络连接关系的梳理过程之中才能真正地梳理出实际的连接关系。这样的网络架构也是 网络流量观察的一个难点 。
Calico 插件的原理
Calico
是一套开源的网络和网络安全方案用于容器、虚拟机、宿主机之间的网络连接可以用在kubernetes、OpenShift、DockerEE、OpenStrack 等 PaaS 或 IaaS 平台上
组件概述 图3
Felix —— Calico 的核心组件运行在每个节点上。主要的功能有接口管理、路由规则、ACL 规则和状态报告
ETCD —— 保证数据一致性的数据库存储集群中节点的所有路由信息。为保证数据的可靠和容错建议至少三个以上 ETCD 节点
Orchestrator Plugin —— 协调器插件负责允许 Kubernetes 或 OpenStack 等原生云平台方便管理 Calico可以通过各自的 API 来配置 Calico 网络实现无缝集成。如 Kubernetes 的 CNI 网络插件
Bird —— BGP 客户端Calico 在每个节点上的都会部署一个 BGP 客户端它的作用是将 Felix 的路由信息读入内核并通过 BGP 协议在集群中分发。当 Felix 将路由插入到 Linux 内核 FIB 中时BGP 客户端将获取这些路由并将它们分发到部署中的其他节点。这可以确保在部署时有效地路由流量
BGP Router Reflector —— 大型网络仅仅使用 BGP Client 形成 Mesh 全网互联的方案就会导致规模限制所有节点需要“N的平方”个连接为了解决这个规模问题可以采用 BGP 的 Router Reflector 的方法使所有 BGP Client 仅与特定 RR 节点互联并做路由同步从而大大减少连接数
Calicoctl —— Calico 命令行管理工具
网络模式概述
Calico 使用的是 BGP 协议来构建容器间网络简单来理解就是将集群间的节点当作边界路由来实现整个网络的互通。BGP 协议之下每一个节点上的所有容器被当作了一个 AS(自治系统而不同的节点之间则通过 BGP 服务来进行路由转发实现连通。实际上Calico 项目提供的 BGP 网络解决方案与 Flannel 的 Host-GW 模式几乎一样。不同之处在于 Calico 基于路由表实现容器数据包转发而 Flannel 则使用 flanneld 进程维护路由信息。这里区别在于 flanneld 会介入到路由的转发过程中导致实际的容器之间通信看起来如同中间会有一个 NAT 服务器的转换这样的情况下旁路模式无法直接获取两个容器之间的流量连接关系需要做一定的推导。Calico 则是基于内核自己的 BGP 路由转发本质上还是容器之间原始数据包的投递所以在宿主机节点上可以旁路采集到整个容器之间的流量关系。
Calico 为了适配三层网络上运行容器间网络还增加了对 IPIP 隧道模式的支持。这种模式下BGP 协议转发的容器网络数据包会通过内核的 IPIP 模块进行封装然后进行宿主机网络的传送。但是本质上还是容器和容器 之间的原始通信数据包的传递没有像 Flannel 那样在跨界点的时候会使用节点 IP 来替换数据包本身发送端的 IP 地址。
Calico 为了灵活适配不同的集群网络规模提供了全互联模式Node-to-Node Mesh和路由反射模式Router Reflection 简称 RR。其中全互联模式适用于小规模集群节点其本身结构简单易于实现。但是缺点在于 BGP 的连接总数是 “N的平方” 其中 N 是节点数在节点增长的情况下连接数增长会极快带来巨大的网络损耗。而路由反射模式则指定一个或多个 BGP Speaker 为 RouterReflection这样就减少了连接总数。不过这种架构实现起来更加的复杂同时对于作为 BGP Speaker 的节点也有更高的要求适合大型集群的网络规划。
Openshift-SDN 插件的原理
Openshift-SDN 是红帽推出的一款容器集群网络方案是部署 Openshift 时默认使用的网络方案。可以通过 oc get Network.config.openshift.io cluster -o yaml 命令来查看当前环境使用 CNI 插件。
组件概述 图4
一套 Openshift-SDN 包含了管控面和数据面
CTRL —— 管控面是一套 Deployment用于自动化地给每个节点分配网段并记录到 CRD 中
Node —— 数据面是一套 DaemonSet用于根据 CRD 变化构建节点网络数据面。包括路由、网卡、流表、IPTABLES 规则
就具体组件来说主要由 Controller、Agent 以及 CNI 的几个部分构成它们各自负责的主要内容包括
1. Controller
负责配置集群级别的容器 CIDR对应 Openshift-SDN 的 CRD clusterNetwork
给新加入的 Node 分配子段对应 Openshift-SDN 的 CRD hostSubnet
观察k8s集群中 namespace、networkpolicy 等对象的变更同步地更新 Openshift-SDN 的 CRD netnamespaces、egressnetworkpolicies专门针对出站的networkpolicy
2. Agent
每次启动时获取集群 clusterNetwork与本地流表做对比当发现有出入就会重新配置本地的集群网络流表、节点上的路由、以及 IPTABLES 规则
观察集群中 Openshift-SDN 的 CRD hostSubnet 的变化配置到达其他 Node 的流表
观察集群中 Openshift-SDN 的 CRD netnamespaces、egressnetworkpolicies 的变化配置相应的租户隔离和出站限制的流表
生成节点上的 CNI 二进制文件并提供 IP 分配功能
针对本节点的每个容器配置对应的流表
3. CNI
负责被 kubelet 调用以进行容器网络的配置和解除
会向 Agent 申请和释放 IP
会配置容器内部的IP和路由
网络模式概述
一言蔽之Openshift-SDN 就是构建了一套容器间的大二层网络虚拟二层中没有三层转发。所有容器的 IP 都属于一个虚拟的 L2 中他们彼此可以互相通过 ARP 请求确认对方物理地址并进行正常的网络发包。不管是 ARP 包还是普通的 IP 包都会被 ovs 流处理并进行必要的封装。
就实际的链路来看在使用 Openshift-SDN 的时候主要会有如下几种情况 同节点的容器与容器访问 包从客户端容器的 Veth到宿主机的 ovs 网桥直接到达对端容器的 Veth 跨节点的容器与容器访问 包从客户端容器的 Veth到宿主机的 ovs 网桥走 vxlan0 端口封装后经过宿主机的协议栈从宿主机的物理网卡发出到对端容器所在宿主机的物理网卡被识别为 Vxlan进入对端机器的 ovs 网桥然后到对端容器的 Veth 容器访问 Node 包从客户端容器的 Veth到宿主机 ovs 网桥因为 Node 的物理网卡 IP 与容器的网络不在一个平面所以直接走内部流表 Table100然后从 tun0 口发出,经过宿主机的协议栈进行路由转发最后走宿主机所在的网络到达某个 Node 的物理网卡 Node 访问本节点的容器 根据宿主机的路由包从 tun0 发出进入宿主机的 ovs 网桥送达对端容器的Veth 容器访问 Service 包从客户端容器的 Veth到宿主机 ovs 网桥从 tun0 发出经过宿主机协议栈受 IPTABLES 规则做了 DNAT 和 MASQUERADE,至此变成了 Node 访问其他节点的容器 Service 的后端回包给容器因为上一步容器访问 Service 时做了 MASQUERADE所以 Service 后端会认为是某个 Node 访问了自己回包给客户端容器所在的 NodeNode 上收到后对照 Conntrack 表确认是之前连接的响应包于是对包的源地址和目的地址做了修改对应之前做的 DNAT 和 MASQUERADE变成了 ServiceIP 访问客户端容器的包。根据 Node 上的路由走 tun0进入 ovs 网桥后直接送到容器的 Veth
这里可以看到Openshift-SDN 设计是实现了纯虚拟二层网络这个和 Flannel 使用 Vxlan 来实现容器间网络有一些不一样。Openshift-SDN 实现的纯虚拟二层网络是一个完整的二层网络相对于 flanneld 还要维护一个自定义的路由表带来的容器之间无法捕获到完整的连接关系不同在 Openshift-SDN 中容器之间的通信是完整的原始数据包流转。
但是由于使用隧道网络协议在宿主机上无法通过旁路的方式直接看到隧道内的网络拓扑关系。所以这里需要在同步到容器的内部网络命名空间中进行采集才能够有效的完成集群网络的可观测性功能的实现。
OVN-Kubernetes 插件的原理
OVN 是基于 OVS 实现到一套网络方案可以虚拟出二层和三层网络。本质来说和 Openshift-SDN 的技术原理是一致的。但是这是 OVS 提供的原生虚拟化网络方案旨在解决传统 SDN 架构比如 Neutron DVR的性能问题。对于 Openshift 本身来说也解决了 Openshift-SDN 对 NetworkPolicy 支持不完整的问题。
组件概述 图5 northbound database —— 存储逻辑交换机、路由器、ACL、端口等的信息目前基于 ovsdb-server未来可能会支持 etcd v3 ovn-northd —— 集中式控制器负责把 northbound database 数据分发到各个 ovn-controller ovn-controller —— 运行在每台机器上的本地 SDN 控制器 southbound database —— 基于ovsdb-server未来可能会支持etcd v3包含三类数据物理网络数据比如 VM 的 IP 地址和隧道封装格式逻辑网络数据比如报文转发方式物理网络和逻辑网络的绑定关系
如果以 Kubernetes 中的部署形式来看它主要分为如下几个组件 ovnkube-db deployment(包含 nb-ovsdb, sb-ovsdb 两个容器) —— 顾名思义部署的是ovn 的两个 db ovnkube-master deployment(包含 ovn-northd, nbctl-daemon, ovnkube-master 三个容器) —— 用来初始化 master 节点并监听集群中对象的变化对 ovn 网络进行相应的配置运行一个 cni 二进制的 http 服务器相应 cmdAdd 和 cmdDel ovnkube daemonset for nodes(ovs-daemons,ovn-controller,ovnkube-node) —— 每台 node 上的守护进程初始化 node ovn-k8s-overlay —— CNI plugin 二进制当 POD 创建/销毁的时候会被 kubelet 调用
网络模式概述
OVN-Kubernetes 主要使用的是 overlay 模式这种模式下 OVN 通过 logical overlay network 连接所有节点的容器。
图6
从本质来说OVN-Kubernetes 和 Openshift-SDN 的运行原理都是一致的都是基于 OVS 构建的一个容器的大二层网络。OVN- Kubernetes 重要的改进点在于其本身对于云原生场景的适配上。重点在于兼容 Kubernetes 以及将容器、Service 网络全部替换为基于 OVN 体系之上的实现。
OVN-Kubernetes 使用 Geneve 协议来作为隧道网络的通信协议这点不同于 Openshift-SDN 使用 VXlan 来在节点间创建网络。所以在使用上还需要注意一些限制 OVN-Kubernetes 不支持设置一个 Kubernetes service 为 local 的外部流量策略或内部流量策略。默认值是 cluster。这个限制能影响你当添加一个 LoadBalancer、NodePort 或一个带有 external IP 的 service sessionAffinityConfig.clientIP.timeoutSeconds service 在一个 OVN-Kuberntes 环境中没有作用但是在 Openshift-SDN 中有用。这个是两个插件之间不兼容的一个地方。 对于双栈网络的集群IPV4 和 IPV6 流量必须使用同样的网络接口作为默认网关。如果达不到这个要求ovnkube-node DaemonSet 中的 POD 在这个主机上会进入 CrashLoopBackOff 状态。所以必须要配置主机支持双栈网络的配置。
总的来说就流量观测上 OVN-Kubernetes 和 Openshift-SDN 的方案都是类似的要直接同步到容器的网络命名空间中进行观测这里也要肯定 SDN 架构确实相对于传统的虚拟局域网架构进一步简化虚拟网络层本身的复杂度为容器网络流量的可观测性扫清了三层转发这一拦路虎有助简化流量可观测性的设计思路。
总结
目前在云原生的场景下非软件行业大型企业用户多倾向于选择功能丰富、有完善技术支持的商业产品 Openshift 来实现自己的云原生数据中心的搭建。这样的环境中容器网络流量观测工具要想做到功能的适配要么是深度对接 OVS 的技术架构通过其本身的底层实现原理来做数据分析得到网络拓扑。要么就是抛开宿主机层面的网络架构复杂性直接进入到容器的二层网络中做数据的搜集。
在一些偏软件行业的企业用户中自研云原生环境也是有很多的。这类环境中大多采用开源的软件组件构建自己的基础设施。而在这些环境中大多数企业会选择 Calico 来实现自己的容器间网络。相对于复杂的 OVS 等虚拟化网络解决方案Calico 提供的 BGP IPIP 方案也满足了 Kubernetes 本身对于容器间网络的基本连接要求。在够用的情况下这类用户会采用更加简单的架构来实现自己的环境所以 Calico 这类方案也得到了广泛的应用。类似 Calico 的网络方案更多的考虑的是利用主机本身提供的网络能力所以在主机上往往可以直接捕获到容器间的通信流量。可以在主机网络流量搜集工具的基础上稍加改造来支持对容器间网络拓扑关系的采集。
理论来说类 SideCar 的模式来采集容器网络几乎可以适配大部分的网络插件下容器与容器之间的网络拓扑采集。但是依然会有一些特例比如在容器网络中实现了三层转发方案的插件比如 Flannel通过配置 Vxlan 的二层转发和三层转发来实现了一个二层网络或者类似于 Calico 不带 IPIP 隧道模式以及 Flannel 的 host-gw 模式本质也是类似于将主机直接当作三层转发网关实现的二层网络。这样的容器网络无论是旁路模式还是 SideCar 模式都无法直接搜集到两个容器之间的连接关系所以在这个基础上通过合理的适配网络架构的特点进行相应的网络流量关系二次分析是可观测性在这些架构上正确工作的一个重要思路。
当然随着 Linux 内核自身可观测性功能的不断发展。相信未来会有更多优秀的方案甚至可能会出现一种更加通用的方案来实现对不同网络架构下的容器间网络的流量观测。
类似于 Calico 不带 IPIP 隧道模式以及 Flannel 的 host-gw 模式本质也是类似于将主机直接当作三层转发网关实现的二层网络。这样的容器网络无论是旁路模式还是 SideCar 模式都无法直接搜集到两个容器之间的连接关系所以在这个基础上通过合理的适配网络架构的特点进行相应的网络流量关系二次分析是可观测性在这些架构上正确工作的一个重要思路。
当然随着 Linux 内核自身可观测性功能的不断发展。相信未来会有更多优秀的方案甚至可能会出现一种更加通用的方案来实现对不同网络架构下的容器间网络的流量观测。
最后
分享一个快速学习【网络安全】的方法「也许是」最全面的学习方法 1、网络安全理论知识2天 ①了解行业相关背景前景确定发展方向。 ②学习网络安全相关法律法规。 ③网络安全运营的概念。 ④等保简介、等保规定、流程和规范。非常重要
2、渗透测试基础一周 ①渗透测试的流程、分类、标准 ②信息收集技术主动/被动信息搜集、Nmap工具、Google Hacking ③漏洞扫描、漏洞利用、原理利用方法、工具MSF、绕过IDS和反病毒侦察 ④主机攻防演练MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础一周 ①Windows系统常见功能和命令 ②Kali Linux系统常见功能和命令 ③操作系统安全系统入侵排查/系统加固基础
4、计算机网络基础一周 ①计算机网络基础、协议和架构 ②网络通信原理、OSI模型、数据转发流程 ③常见协议解析HTTP、TCP/IP、ARP等 ④网络攻击技术与网络安全防御技术 ⑤Web漏洞原理与防御主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作2天 ①数据库基础 ②SQL语言基础 ③数据库安全加固
6、Web渗透1周 ①HTML、CSS和JavaScript简介 ②OWASP Top10 ③Web漏洞扫描工具 ④Web渗透工具Nmap、BurpSuite、SQLMap、其他菜刀、漏扫等 恭喜你如果学到这里你基本可以从事一份网络安全相关的工作比如渗透测试、Web 渗透、安全服务、安全分析等岗位如果等保模块学的好还可以从事等保工程师。薪资区间6k-15k。
到此为止大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗
想要入坑黑客网络安全的朋友给大家准备了一份282G全网最全的网络安全资料包免费领取 扫下方二维码免费领取
有了这些基础如果你要深入学习可以参考下方这个超详细学习路线图按照这个路线学习完全够支撑你成为一名优秀的中高级网络安全工程师
高清学习路线图或XMIND文件点击下载原文件
还有一些学习中收集的视频、文档资源有需要的可以自取 每个成长路线对应板块的配套视频 当然除了有配套的视频同时也为大家整理了各种文档和书籍资料工具并且已经帮大家分好类了。 因篇幅有限仅展示部分资料需要的可以【扫下方二维码免费领取】
