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 it
CAP_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 normally
(MoeLove) ➜ ~ docker run --rm -it -u root redis:alpine sh /data # whoami root /data # ping -c 1 moelove.info PING moelove.info (18.104.22.168): 56 data bytes 64 bytes from 22.214.171.124: 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 the
pingThe 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 (126.96.36.199): 56 data bytes ping: permission denied (are you root?)
If IPv6 is not completely disabled on the host (via kernel parameters
ipv6.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 default
CAP_NET_ADMINTherefore, the attacker cannot directly configure it as the IP of man in the middle attack, and cannot use iptables
REDIRECTFlow, and not available
IP_TRANSPARENT。 But attackers can still use it
CAP_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 repository
kubernetes-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:
- Juniper Contrail Networking
- OpenShift SDN
- 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 the
CAP_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 (188.8.131.52): 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 of
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 by
COMPOSE_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
Kubernetes v1.19.0-beta1 has been released this week!
- #91113 and ා 91481 in the
kubectl create deploymentWhen, added
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].