Networking overview

It seems once people understand the basics of containers, networking is one of the first aspects they begin experimenting with. And regarding networking, it takes very little experimentation before ending up on the deep end of the pool. – Podman documentation

This section deals with one of the more comprehensive topics when working with containers. For any readers having experience with networking in Docker, they should expect a substantially different approach to the subject. This page gives a brief introduction to the ideas related to networking and the remaning parts of the networking chapter covers them in more detail.

The two central concepts of container networking are: Networks and network driver. The former are independent objects in Kleene and the latter is a property of containers. Networks are used to provide different kinds of connectivity to containers, and the capabilities of using networks, and networking in general, is determined by which kind of network driver the container has.

Network types

Three different kinds of networks exists, and each network is represented by an interface on the host.

  • loopback: Kleene creates a loopback interface on the host for the network. This has historically been a classical way to provide networking for jails in FreeBSD. It is the default network type with Klee.

  • bridge: Kleene creates a bridge interface on the host for the network. The bridge network can be used to (logically) link interfaces on the host machine (physical or virtual). The bridge network is used for containers with the vnet network driver (see below).

  • custom: The user determines which interface on the host should be used for the network. For instance, if the container should have an IP directly on the physical interface, the default loopback interface (lo0) or more exotic use cases. The user is expected to take care of creating/destroying the interface, if needed.

Container network drivers

The networking capabilities of a container is determined by it’s network driver. There are four different network drivers, and only one can be used at the same time. The drivers are derived directly from the underlying jail-parameters.

  • host (default driver): Inherit the network configuration from the host. The container is able to see all ips of all interfaces. However, the container can’t manipulate the interfaces, such as adding/remove IP-addresses with ifconfig etc. This network driver provides the least amount of isolation since the container can see (and use) all IP-addresses on the host, including those used by other containers. It is not possible to connect to any networks with this driver, and since it does not require a network, it is the default driver. However, in production setups it is recommended to use networks and ipnet/vnet drivers instead, since they provide much better isolation from the host and other containers.

  • ipnet: Inherit the network configuration from the host, but restrict which IP-addresses of the host that is accesible to the container. All interfaces of the host are visible within the container but not the IP’s. Only assigned IP’s are visible within the container, and configuring network interfaces using tools such as ifconfig(8) is prohibited. A few pro’s and con’s of ipnet-containers:

    • It is lightweight way of providing connectivity to a container while retaining isolation from the host and other containers.

    • Ipnet containers can connect to all network types.

    • The IP’s assigned to the container is also visible from the host so getting an overview of IP usage of ipnet-containers is straightforward.

    • Access to localhost aka. 127.0.0.1 is prohibited by default. This might require additional configuration of applications that expects this IP to be accessable.

    • The restricted networking environment limits the possibilites of what you can do within the container. For instance, it is not possible to setup a firewall or manipulating routes, network interfaces etc. Use the vnet driver in that case.

  • vnet: vnet-containers has their own virtual network stack, such as a dedicated loopback interface, routing table, firwall capabilities etc. Vnet-containers are connected through a virtual cross-over cable represented by a pair of epair(4) interfaces. One of these is designated to the container and the other resides on the host, where it is added to a bridge interface. A few pro’s and con’s of vnet-containers:

    • Because vnet-containers have their own network stack, they can create virtual interfaces, manipulate existing ones, and run their own firewall. This makes them ideal for more complicated networking requirements.

    • Slightly more host and container configuration is needed compared to ipnet-containers since epair interfaces has to be allocated/configured and gateways has to be added during container startup.

    • Since the network-stack is isolated from the host, the networking configuration of the container is only visible from within the container.

    • vnet-containers can only connect to bridge-networks.

  • disabled: Networking capabilites are disabled. Containers using this driver can see all network interfaces of the host but none of the IP-addresses.

Next steps

Go to on of driver-specific pages for introductory walk-throughs:

If you have experience with FreeBSD jails and know the different approaches to networking, the walk-throughs should be very familiar and hopefully it shows how Kleene incorporates it.