kubectl cp漏洞CVE-2019-1002101分析
Kube-proxy IPVS添加flag ipvs-strict-arp
近期bug fix数据分析
——本期更新内容
kubectl cp漏洞
近期kubernetes的kubectl cp命令发现安全问题(CVE-2019-1002101), 该问题严重程度比较高,建议将kubectl升级到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解决此问题 。
kubectl cp命令允许用户在容器和主机之间复制文件,其基本原理是:
-
在源地址将文件打包。
-
打包输出内容作为stream流通过网络传递给目标地址。
-
传递路径包括:apiserver、kubelet、runtime
-
stream流在目的地址作为tar的输入,解压。
具体执行过程可以参考 kubernetes/pkg/kubectl/cmd/cp.go 文件中的copyToPod和copyFromPod两个函数。
在这个过程中,如果容器中的tar二进制文件是恶意的,它可以运行任何代码并输出意外的恶意结果。当调用kubectl cp时,攻击者可以使用它将文件写入用户计算机上的任何路径,仅受本地用户的系统权限限制。
目前社区在1.11-1.14版本均修复了该问题,具体修复方式可参考:
https://github.com/kubernetes/kubernetes/pull/75037
用户可以通过kubectl version --client命令查看自己使用的kubectl版本,并升级到1.11.9,1.12.7,1.13.5或1.14.0版本以修复该漏洞。
Kube-proxy IPVS添加 flag ipvs-strict-arp
首先了解些背景知识。
kube-proxy的ipvs模式会将 clusterIP/externalIP 等绑定到节点上名为 kube-ipvs0 的dummy设备,以确保节点上的ipvs规则可以对访问这些地址的流量作转发。
在1.13版本中,引入一个操作
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
以禁止IPVS模式下对 kube-ipvs0 dummy设备上绑定的ip的ARP回复,具体可参考pr #70530,该改动是为了修复ipvs模式下load banlancer类型service不能正常使用的问题(issue:#59976)。
而本次的buf fix则是跟前面的改动有关,因为前面的改动虽然解决了loadbalancer的问题,但是又引入了其他问题:有些CNI插件在主机和容器间的连接会用到ARP协议。因此我们看到有些用户升级到1.13后反馈下面的问题:
issue#72779: kube-proxy v1.13.0 and 1.13.1 brokes services with externalIPs
issue#71555: kube-proxy/IPVS: arpignore and arpannounce break some CNI plugins
而本bug fix也很简单,就是为kube-proxy加了一个启动参数 ipvs-strict-arp ,默认为0,即不改变节点上的ARP配置,如果需要改变,则设置该参数值为1。
不得不说,这只是一个规避方案,无论是否使用该参数,kube-proxy ipvs模式下总有一部分功能受影响。
但是IPVS模式本身就有它独特的优势,是iptables所没有的,在这些优势的基础上,一定要ipvs实现原来iptables实现的所有功能似乎也不太合理。
近期bug fix数据分析
近期在我们关注的1.13版本(1.13.5之后)没有比较重要的bug fix发布,为数不多的几条也都是集群部署、第三方云提供商、e2e测试相关,不需要太多关注。
前文提到的CVE-2019-1002101漏洞也是在1.13.5版本之前已经修复的,上次的bug fix已经覆盖到,大家如果有兴趣深入研究的话可以根据本文提供的pr链接学习。
最后我们看下具体数据:
如下为所有bug fix的汇总信息:
相关服务请访问:https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69908804/viewspace-2641706/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/69908804/viewspace-2641706/