MoeLove

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

 2085  5 分钟

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

Docker v19.03.11 发布

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

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

例如： 在容器内使用 root 用户，可以正常执行 ping 命令

(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 命令会提示无权限

(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 之前版本

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

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

  • 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】

TheMoeLove

相关文章：

加载评论