CVE-2019-11246漏洞解读
近期kubernetes的kubectl cp命令发现安全问题(CVE-2019-11246)，该问题严重程度比较高，建议将kubectl升级到Kubernetes 1.12.9, 1.13.6, 1.14.2 或更新的版本以解决此问题。由于对3月份披露的漏洞CVE-2019-1002101更新不完整导致了该漏洞的出现。
kubectl cp命令允许用户在容器和主机之间复制文件，其基本原理是：
在源地址将文件打包。
打包输出内容作为stream流通过网络传递给目标地址。
传递路径包括：apiserver、kubelet、runtime
stream流在目的地址作为tar的输入，解压。
要从容器中复制文件到用户宿主机，Kubernetes在容器内运行tar命令，并将打包结果返回，kubectl将其解压到用户宿主机。这个过程中如果容器中的tar二进制文件是恶意的，它可以运行任何代码并输出恶意结果。当用户使用kubectl cp时，攻击者可以使用它将文件写入用户宿主机上的任何路径，且仅受本地用户的系统权限限制。
目前社区在1.12-1.14版本均修复了该问题，具体修复方式可参考：
https://github.com/kubernetes/kubernetes/pull/76788
用户可以通过kubectl version --client命令查看自己使用的kubectl版本，并升级到1.12.9, 1.13.6, 1.14.2 或更新的版本以修复该漏洞。
1
Kubernetes近期重要bug fix分析
# 79451：当PodSandbox创建失败时，即使Pod重启策略为Never也重新创建PodSandbox
https://github.com/kubernetes/kubernetes/pull/79451
该问题的背景是#79398这个issue，描述的现象是当Pod的重启策略是“Never”时，如果一旦kubelet创建PodSandbox失败，那么此时Pod的状态将一直停留在“ContainerCreating”，并且用户的应用容器也未被创建。在PR中的修复策略是，不管Pod的重启策略是”Never”或者其他，在PodSandbox创建失败时，统一重新创建。PodSandbox创建成功后，用户的应用容器则根据Pod的重启策略决定失败后是否重启。
# 75223：在计算Pod QoS class时将Init container也考虑在内
https://github.com/kubernetes/kubernetes/pull/75223
该问题的背景是# 75212这个issue，描述的现象是pod中含有Init container与其他container，当Init container配置了cpu、memory资源需求，且其他container没有配置cpu、memory资源需求，此时得出的结论该Pod的QoS class是BestEffort。社区成员认为这是不正确的，容器的资源需应该与生命周期独立开来，因此PR中修复的策略是在计算Pod QoS class时将Init container也考虑在内。
1
近期bug fix数据分析
近期Bug数量共计14个，分类数量和占比统计如下：
严重程度数量统计如下（横坐标5为最高，0为最低）：
如下为近期Bug Fix的汇总信息：
