K8s ecological weekly report | loopholes affecting almost all k8s clusters

Time:2020-9-24

The k8s ecological weekly mainly contains some information that I have been exposed to and recommended on a weekly basis. Welcome to the k8s ecology column.

Docker v19.03.11 release

Only a week after the release of v19.03.10, docker released a new version of v19.03.11. This version is a security repair version, which prevents address spoofing by disabling IPv6 Routing address broadcasting (RA). The corresponding vulnerability is cve-2020-13401.

In the default configuration of docker, the container network interface is a virtual Ethernet link to the host (veh interface). In this configuration, if an attacker can run the process as root in the container, he can use itCAP_NET_RAWAbility to send and receive packets to the host at will.

For example, if root is used in the container, it can be executed normallypingcommand

(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

Using a non root user in the container, execute thepingThe command prompts for no permission

(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?)

If IPv6 is not completely disabled on the host (via kernel parametersipv6.disable=1)The network interface on the host can be configured by itself. If the configuration item is/proc/sys/net/ipv6/conf/*/forwarding == 0That means IPv6 forwarding is disabled on the interface. The global static configuration can be seen in the following locations:

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

In addition, there is a default configuration about whether to receive RA messages. If the configuration item is/proc/sys/net/ipv6/conf/*/accept_ra == 1Indicates that the interface receives RA messages by default. The global static configuration can be seen in the following locations:

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

The combination of the above two system default configurations indicates that the system accepts routing broadcast (RA) messages and uses it to configure the IPv6 network stack (SLAAC). If you are familiar with IETF RFC 4861, you should know that ICMPv6 RA has a good intention, but it does have security risks.

In a network that has not yet used IPv6, the dual stack host is dormant and waits for the final RA message to wake up its IPv6 connection. Attackers can make malicious RA messages, obtain dual protocol nodes in the network to configure their IPv6 addresses, and use the attacker’s system as their default gateway. In this way, man in the middle attack can be implemented very simply. In fact, RFC 6104 has recorded this problem for a long time, and there are many related solutions. We will not start here. There are too many things involved.

In this vulnerability, if an attacker sends a malicious RA message (Rogue RA) through the container, the host can be reconfigured and part or all IPv6 communication of the host can be redirected to the container controlled by the attacker.

Even if there is no IPv6 traffic before, if the DNS server returns a (IPv4) and AAAA (IPv6) records, many HTTP libraries will first try to make an IPv6 connection, and then go back to IPv4. This gives the attacker an opportunity to create a response.

If the host has a vulnerability like cve-2019-3462 of apt last year, the attacker may gain host privileges.

In general, docker container is not configured by defaultCAP_NET_ADMINTherefore, the attacker cannot directly configure it as the IP of man in the middle attack, and cannot use iptablesNATperhapsREDIRECTFlow, and not availableIP_TRANSPARENT。 But attackers can still use itCAP_NET_RAWAbility, and implement tcp/ip stack in user space.

After talking about this vulnerability related to docker, let’s talk about some other issues.

Similar to this vulnerability, there are alsoKubernetesBut it is not kubernetes’ own vulnerability, but kubelet relies on in the official installation source repositorykubernetes-cniCNI package, also has vulnerability cve-2020-10749

The affected versions are:

  • kubelet v1.18.0-v1.18.3
  • kubelet v1.17.0-v1.17.6
  • Kubelet before v1.16.11

Third party component related vulnerability information:

  • Calico and calico enterprise (cve-2020-13597) vulnerability information tta-2020-001 can be found here https://www.projectcalico.org… see;
  • CNI plugins version before 0.8.6 (cve-2020-10749), see https://github.com/containern… ;
  • All versions of flannel;
  • Weave net v2.6.3 prior;

The following third party components are not currently affected by this vulnerability:

  • Cilium
  • Juniper Contrail Networking
  • OpenShift SDN
  • OVN-Kubernetes
  • Tungsten Fabric

Combined with the previous explanation of this vulnerability, you must also see that the easiest way to solve this vulnerability is:

  • Update the relevant components to the latest version (including the repair content) (up to now, all affected components except flannel have released new versions to solve this vulnerability);
  • You can disable receiving RA messages in the system (if you don’t need RA messages);
  • You can also disable theCAP_NET_RAWCapabilities, such as:
(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 release

Docker compose is a very convenient and flexible tool. You should not be unfamiliar with it. Some time ago, docker opened source the compose specification, and the community is gradually growing.

This release of v1.26.0 contains a lot of noteworthy content:

  • Added pair ofdoker contextAnd,contextVery easy to use! Before docker con this year, docker Inc. also reached a cooperation with azure to accelerate the development / deployment from local to cloud. The specific operation is also realized through context;
  • Supported byCOMPOSE_COMPATIBILITYEnvironment variables configure their capabilities;

If you are interested in this version, please refer to its ReleaseNote

Kube ovn v1.2 release

Kube ovn is the first project to appear in the “k8s ecological weekly report”. Here is a brief introduction. It is a kubernetes network component based on ovn. By translating the mature network functions in openstack domain to kubernetes, it can meet the more complex basic environment and application compliance requirements.

Kube ovn has five main functions: the binding of namespace and subnet, access control between subnets, static IP allocation, dynamic QoS, distributed and centralized gateway, embedded loadbalancer.

The following important updates are included in this release of v1.2:

  • Start to support ovs-dpdk to support high-performance dpdk applications;
  • It supports the use of BGP to announce the pod IP route to the external network;
  • After the creation, support the modification of the subnet CIDR (I personally think this function is particularly useful, and the network planning also has the actual demand of dynamic adjustment);
  • When the subnet gateway is modified, the route can be changed automatically;

If you are interested in this version, please refer to its relasenote

Upstream progress

Kubernetes v1.19.0-beta1 has been released this week!

  • #91113 and ා 91481 in thekubectl create deploymentWhen, added--portOption of;

Another happy change comes from etcd:

  • #11946 added one for etcd--unsafe-no-fsyncTo disable file synchronization. This is great for local development / CI testing!

Welcome to subscribe my official account number [MoeLove].

K8s ecological weekly report | loopholes affecting almost all k8s clusters