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