K8S 生态周报| 几乎影响全部 k8s 集群的漏洞

时间 2020-06-10

原文原文链接

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。

Docker v19.03.11 发布

距离 v19.03.10 发布仅一周时间，Docker 又发布了新版本 v19.03.11 。此版本是一个安全修复版本，经过禁用了 IPv6 路由地址广播（RA）从而防止地址欺骗，对应的漏洞为 CVE-2020-13401 。git

在 Docker 的默认配置中，容器网络接口是指向主机（veth 接口）的虚拟以太网连接，在此配置下，若是一个攻击者能够在容器中以 root 身份运行进程的话，那么他是可使用 CAP_NET_RAW 能力，向主机任意发送和接收数据包的。github

例如：在容器内使用 root 用户，能够正常执行 ping 命令redis

(MoeLove) ➜  ~ docker run --rm -it -u root redis:alpine sh
/data # whoami
root
/data # ping -c 1 moelove.info
PING moelove.info (185.199.108.153): 56 data bytes
64 bytes from 185.199.108.153: seq=0 ttl=49 time=54.389 ms

--- moelove.info ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 54.389/54.389/54.389 ms

在容器内使用非 root 用户，执行 ping 命令会提示无权限docker

(MoeLove) ➜  ~ docker run --rm -it -u redis redis:alpine sh
/data # whoami
redis
/data $ ping -c 1 moelove.info
PING moelove.info (185.199.109.153): 56 data bytes
ping: permission denied (are you root?)

若是没有在主机上彻底禁用 IPv6 （经过内核参数 ipv6.disable=1）, 那么主机上的网络接口能够本身进行配置。若是配置项为 /proc/sys/net/ipv6/conf/*/forwarding == 0 那表示该接口禁用了 IPv6 转发。全局的静态配置能够在如下位置看到：安全

(MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/forwarding
1

另外，还有一个默认配置是关因而否接收 RA 消息的，若是配置项为 /proc/sys/net/ipv6/conf/*/accept_ra == 1，则表示该接口默认接收 RA 消息。全局的静态配置能够在如下位置看到：服务器

(MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/accept_ra 
1

上述的两个系统默认配置的组合，表示系统接受路由广播（RA）消息，而且使用它配置 IPv6 网络栈（SLAAC）。若是熟悉 IETF RFC 4861 的小伙伴应该知道，ICMPv6 RA 虽然本意是好的，但它确实存在安全风险。网络

在还没有使用 IPv6 的网络中，双栈主机处于休眠状态，并等待最终的 RA 消息来唤醒其 IPv6 链接。攻击者能够制做恶意的 RA 消息，获取网络中的双协议节点以配置其 IPv6 地址，并利用攻击者的系统做为其默认的网关。这样即可很简单的实施中间人攻击了。在 RFC 6104 中其实早就记录过这个问题，也有不少相关的解决方案，此处就不展开了，涉及的东西太多了。分布式

对应到这次漏洞中，若是攻击者经过容器发送恶意 RA 消息（rogue RA），则能够从新配置主机，将主机的部分或者所有 IPv6 通讯都重定向到攻击者控制的容器。工具

即便以前没有 IPv6 流量，若是 DNS 服务器返回 A（IPv4）和 AAAA（IPv6）记录的话，不少 HTTP 库将会首先尝试进行 IPv6 链接，而后再回退到 IPv4 。这就为攻击者提供了制造响应的机会。性能

若是主机刚好有相似去年 apt 的 CVE-2019-3462 这种漏洞的话，则攻击者即可能获取主机权限。

整体而言，Docker 容器默认没有配置 CAP_NET_ADMIN 能力，因此攻击者没法直接将其配置为中间人攻击的 IP，没法使用 iptables 进行 NAT 或者 REDIRECT 流量，也不能使用 IP_TRANSPARENT。可是攻击者仍然可使用 CAP_NET_RAW 能力，并在用户空间实现 TCP/IP 堆栈。

聊完 Docker 相关的这个漏洞，这里就顺便展开聊聊相关的一些其余问题吧。

与此漏洞相似的，受影响的还有 Kubernetes ，但并非 Kubernetes 自身的漏洞，而是官方安装源仓库中，kubelet 依赖的 kubernetes-cni CNI 包，也存在漏洞 CVE-2020-10749

受影响版本为：

kubelet v1.18.0-v1.18.3
kubelet v1.17.0-v1.17.6
kubelet v1.16.11 以前版本

第三方组件相关的漏洞信息：

Calico 和 Calico Enterprise (CVE-2020-13597) 漏洞信息 TTA-2020-001 可在此处 https://www.projectcalico.org... 查看；
CNI Plugins v0.8.6 以前版本（CVE-2020-10749），详情见 https://github.com/containern...；
Flannel 所有版本；
Weave Net v2.6.3 以前版本；

如下第三方组件目前未受这次漏洞影响：

Cilium
Juniper Contrail Networking
OpenShift SDN
OVN-Kubernetes
Tungsten Fabric

结合前面我对此漏洞的说明，想必你也看到了，解决此漏洞最简单的方法是：

更新相关组件到最新（包含修复内容）的版本（截至目前，相关受影响组件中，除 Flannel 外，均已发布新版原本解决此漏洞）；
能够在系统中禁止接收 RA 消息（若是你不须要 RA 消息的话）；
也能够禁用容器的 CAP_NET_RAW 能力，例如：

(MoeLove) ➜  ~ docker run --cap-drop CAP_NET_RAW --rm -it -u root redis:alpine sh
/data # ping -c 1 moelove.info
PING moelove.info (185.199.108.153): 56 data bytes
ping: permission denied (are you root?)

Docker Compose v1.26.0 发布

Docker Compose 是一个很方便灵活的工具，你们应该不会陌生。前段时间 Docker 将 Compose 规范开源后，社区在逐步成长中。

本次发布的 v1.26.0 中，包含了不少值得注意的内容：

添加了对 doker context 的支持，context 很是好用！Docker Inc. 在今年的 Docker Con 以前还和 Azure 达成了合做，加速从本地到云的开发/部署等，具体操做上也都是经过 context 实现的；
支持经过 COMPOSE_COMPATIBILITY 环境变量配置其能力；

对此版本感兴趣的朋友请参考其 ReleaseNote

Kube-OVN v1.2 发布

Kube-OVN 是首次出如今「K8S 生态周报」中的项目，稍微作下介绍。它是一款基于 OVN 的 Kubernetes 网络组件，经过将OpenStack领域成熟的网络功能平移到Kubernetes，来应对更加复杂的基础环境和应用合规性要求。

Kube-OVN主要具有五大主要功能：Namespace 和子网的绑定，以及子网间访问控制，静态IP分配，动态QoS，分布式和集中式网关，内嵌 LoadBalancer。

本次发布的 v1.2 中包含了如下重要更新：

开始支持 OVS-DPDK 以便于支持高性能 dpdk 应用；
支持使用 BGP 将 Pod IP 路由宣告到外部网络；
在建立后，支持修改子网 CIDR （我我的以为这个功能特别有用，网络规划也有动态调整的实际需求）；
当子网网关修改后，路由能够自动更改；

对此版本感兴趣的朋友请参考其 RelaseNote

上游进展

本周 Kubernetes v1.19.0-beta1 已经发布！

#91113 和 #91481 在 kubectl create deployment 时，增长了 --port 的选项；

另外一个值得开心的变动来自 etcd :

#11946 为 etcd 添加了一个 --unsafe-no-fsync 的选项，能够禁止文件同步。这对于本地开发/CI 测试都是很是好的！

欢迎订阅个人文章公众号【MoeLove】