“K8S Ecology Weekly” mainly contains some recommended weekly information related to K8S ecology that I have come into contact with. Welcome to subscribe zhihu column “K8S Ecology”.

Docker v19.03.11 release

Just one week after the release of v19.03.10, Docker has released a new version, v19.03.11. This release is a security fix that prevents address spoofing by disabling IPv6 routing address broadcast (RA). The corresponding vulnerability is CVE-2020-13401.

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

For example, if the root user is used in the container, the ping command can be successfully executed

(MoeLove) ➜  ~ docker run --rm -it -u root redis:alpine sh
/data # whoami
root
/data # ping -c 1 moelove.infoPING moelove.info (185.199.108.153): 56 data bytes 64 bytes from 185.199.108.153: Seq =0 TTL =49 time= 54.489 ms -- ping statistics -- transmitted packets, 1 packets received 0% packet loss round-trip min/ AVG/Max = 54.389/54.389/54.389msCopy the code

If you run the ping command as a non-root user in the container, a message is displayed indicating that the user has no permission

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

If IPv6 is not completely disabled on the host (via the kernel parameter ipv6.disable=1), the network interface on the host can configure itself. If the configuration item is /proc/sys/net/ipv6/conf/*/forwarding == 0, 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 1Copy the code

In addition, there is a default configuration for receiving RA messages. If the configuration item is /proc/sys/net/ipv6/conf/*/accept_ra == 1, it indicates 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 1Copy the code

The combination of the two system defaults above means that the system accepts a Routing Broadcast (RA) message and uses it to configure the IPv6 network stack (SLAAC). If you are familiar with IETF RFC 4861, you should know that ICMPv6 RA is well-intentioned, but it does pose security risks.

On networks that do not yet use IPv6, the dual-stack host sleeps and waits for a final RA message to wake up its IPv6 connection. An attacker can make malicious RA messages, obtain dual-protocol nodes on the network to configure their IPv6 addresses, and use the attacker’s system as its default gateway. This makes man-in-the-middle attacks very easy. This problem has been documented in RFC 6104, and there are many related solutions, but I won’t expand here, there are too many things involved.

Corresponding to this vulnerability, if an attacker sends rogue RA messages through the container, the host can be reconfigured to redirect some or all of the host’s IPv6 traffic to the container controlled by the attacker.

If A DNS server returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to make an IPv6 connection first and then fall back to IPv4, even if there is no IPv6 traffic before. This provides an opportunity for an attacker to create a response.

If the host happens to have a vulnerability like cVE-2019-3462 in last year’s APT, then the attacker may gain access to the host.

Generally speaking, Docker containers are not configured with CAP_NET_ADMIN capability by default, so attackers cannot directly configure it as an IP for manin-middle attack, cannot use IPtables for NAT or REDIRECT traffic, and cannot use IP_TRANSPARENT. But an attacker can still use the CAP_NET_RAW capability and implement a TCP/IP stack in user space.

After talking about this docker-related bug, let’s talk about some other issues.

Similar to this vulnerability, affected Kubernetes, but not Kubernetes vulnerability, but the official installation source repository, Kubelet depends on kubernetes-CNI CNI package, also exists vulnerability CVE-2020-10749

The affected versions are:

  • Kubelet v1.18.0 – v1.18.3
  • Kubelet v1.17.0 – v1.17.6
  • Kubelet versions prior to V1.16.11

Vulnerability information related to third-party components:

  • The Calico and Calico Enterprise (CVE – 2020-13597) vulnerability information TTA – 2020-001 May be www.projectcalico.org/security-bu here… To view;
  • CNI Plugins earlier than V0.8.6 (CVE-2020-10749), see github.com/containerne…
  • Flannel all versions;
  • Weave Net version before 2.6.3;

The following third-party components are not affected by the vulnerability:

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

As you can see from my previous description of this vulnerability, the easiest way to solve this vulnerability is:

  • Update relevant components to the latest version (including fixes) (To date, all affected components, except Flannel, have released new versions to address this vulnerability);
  • You can disable receiving RA messages in your system (if you don’t need RA messages).
  • You can also disable the containerCAP_NET_RAWCompetencies, 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?)
Copy the code

Docker Compose is released in V1.26.0

Docker Compose is a convenient and flexible tool for Docker swarm. Docker made the Compose specification open source some time ago, and the community is growing.

In v1.26.0, there are a number of things worth noting:

  • Added todoker contextSupport,contextVery useful! Docker Inc. also reached a cooperation with Azure before Docker Con this year to accelerate development/deployment from local to cloud, and specific operations are also achieved through context;
  • Supported byCOMPOSE_COMPATIBILITYEnvironment variables configure their capabilities;

Please refer to ReleaseNote for those interested in this release

Kube – OVN v1.2 release

Kube-ovn is the first project to appear in “K8S Ecology Weekly”, a brief introduction. Kubernetes is an OVN-based Kubernetes networking component that addresses the more complex infrastructure and application compliance requirements by shifting the mature networking capabilities of OpenStack to Kubernetes.

Kube-ovn has five main functions: Namespace and subnet binding, as well as inter-subnet access control, static IP allocation, dynamic QoS, distributed and centralized gateway, LoadBalancer embedded.

V1.2 contains the following important updates:

  • Support for OVS-DPDK began in order to support high-performance DPDK applications;
  • BGP can be used to advertise Pod IP routes to external networks.
  • Support for modifying subnet CIDR after creation (I personally find this feature particularly useful, and network planning has practical requirements for dynamic adjustment);
  • After the subnet gateway is modified, routes can be automatically changed.

For those interested in this version please refer to RelaseNote

Progress in the upstream

Kubernetes V1.19.0-Beta1 has been released this week!

  • # 91113 和 # 91481 在 kubectl create deployment, has increased--portThe options;

Another happy change comes from etCD:

  • # 11946One was added for ETCD--unsafe-no-fsyncOption to disable file synchronization. This is great for native development /CI testing!

Please feel free to subscribe to my official account [MoeLove]