This post was contributed by Ant Group, a large-scale digital payment platform. Jianfeng and Yong are engineers at Ant Group working on infrastructure systems, and contributors to gVisor.
At Ant Group, we are committed to keep online transactions safe and efficient. Continuously improving security for potential system-level attacks is one of many measures. As a container runtime, gVisor provides container-native security without sacrificing resource efficiency. Therefore, it has been on our radar since it was released.
gVisor has implemented the RACK (Recent ACKnowledgement) TCP loss-detection algorithm in our network stack, which improves throughput in the presence of packet loss and reordering.
Hardware virtualization is often seen as a requirement to provide an additional isolation layer for untrusted applications. However, hardware virtualization requires expensive bare-metal machines or cloud instances to run safely with good performance, increasing cost and complexity for Cloud users. gVisor, however, takes a more flexible approach.
In the previous two posts we talked about gVisor’s security design principles as well as how those are applied in the context of networking. Recently, a new container escape vulnerability (CVE-2020-14386) was announced that ties these topics well together. gVisor is not vulnerable to this specific issue, but it provides an interesting case study to continue our exploration of gVisor’s security. While gVisor is not immune to vulnerabilities, we take several steps to minimize the impact and remediate if a vulnerability is found.
In our first blog post, we covered some secure design principles and how they guided the architecture of gVisor as a whole. In this post, we will cover how these principles guided the networking architecture of gVisor, and the tradeoffs involved. In particular, we will cover how these principles culminated in two networking modes, how they work, and the properties of each.