6.8 KiB
####> This option file is used in: ####> podman podman-container.unit.5.md.in, create, kube play, podman-kube.unit.5.md.in, pod create, podman-pod.unit.5.md.in, run ####> If file is edited, make sure the changes ####> are applicable to all of those. << if is_quadlet >>
Network=mode
<< else >>
--network=mode, --net
<< endif >>
Set the network mode for the <<container|pod>>.
<< if is_quadlet >> Special cases:
-
If the
nameof the network ends with.network, a Podman network calledsystemd-$nameis used, and the generated systemd service contains a dependency on the$name-network.service. Such a network can be automatically created by using a$name.networkQuadlet file. Note: the corresponding.networkfile must exist. -
If the
nameends with.container, the container will reuse the network stack of another container created by$name.container. The generated systemd service contains a dependency on$name.service. Note: the corresponding.containerfile must exist. << endif >>
Valid mode values are:
-
bridge[:OPTIONS,...]: Create a network stack on the default bridge. This is the default for rootful containers. It is possible to specify these additional options:
- alias=name: Add network-scoped alias for the container.
- ip=IPv4: Specify a static IPv4 address for this container.
- ip6=IPv6: Specify a static IPv6 address for this container.
- mac=MAC: Specify a static MAC address for this container.
- interface_name=name: Specify a name for the created network interface inside the container.
- host_interface_name=name: Specify a name for the created network interface outside the container.
Any other options will be passed through to netavark without validation. This can be useful to pass arguments to netavark plugins.
For rootless bridge networks, port forwarding uses
rootlessportby default. Settingrootless_port_forwarder="pasta"in the[network]section of containers.conf(5) switches to pasta's kernel-level forwarding (viapesto), which preserves the original client source IP address inside the container. This option is experimental and its behavior is subject to change.For example, to set a static IPv4 address and a static mac address, use
--network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99. -
<network name or ID>[:OPTIONS,...]: Connect to a user-defined network; this is the network name or ID from a network created by podman network create. It is possible to specify the same options described under the bridge mode above. Use the --network option multiple times to specify additional networks.
For backwards compatibility it is also possible to specify comma-separated networks on the first --network argument, however this prevents you from using the options described under the bridge section above. -
none: Create a network namespace for the container but do not configure network interfaces for it, thus the container has no network connectivity.
-
container:id: Reuse another container's network stack.
-
host: Use the host's network namespace for the container instead of creating an isolated namespace. Warning: This gives the container full access to abstract Unix domain sockets and to TCP/UDP sockets bound to localhost. Since these mechanisms are often used to prevent access to sensitive system services, isolating them from access by external entities, use of this option may be considered a security vulnerability.
-
ns:path: Path to a network namespace to join.
-
private: Create a new namespace for the container. This uses the bridge mode for rootful containers and pasta for rootless ones.
-
pasta[:OPTIONS,...]: use pasta(1) to create a user-mode networking stack.
This is the default for rootless containers and only supported in rootless mode.
By default, IPv4 and IPv6 addresses and routes, as well as the pod interface name, are copied from the host. Port forwarding preserves the original source IP address. Options described in pasta(1) can be specified as comma-separated arguments.
In terms of pasta(1) options, --config-net is given by default, in order to configure networking when the container is started, and --no-map-gw is also assumed by default, to avoid direct access from container to host using the gateway address. The latter can be overridden by passing --map-gw in the pasta-specific options (despite not being an actual pasta(1) option).
For better integration with DNS handling, --dns-forward 169.254.1.1 is passed by default, and this address is added to resolv.conf(5) as first resolver. It is possible to pass --dns-forward explicitly in case a different IP address should be used.
To make thehost.containers.internal/etc/hosts entry work and allow connections to the host, --map-guest-addr 169.254.1.2 is passed by default. Again, it can be set explicitly to choose a different IP address.
Also, -t none and -u none are passed if, respectively, no TCP or UDP port forwarding from host to container is configured (via Podman's --publish or by passing the pasta -t/-u options directly), to disable automatic port forwarding based on bound ports. Similarly, -T none and -U none are given to disable the same functionality from container to host.
All options can also be set in containers.conf(5); see thepasta_optionskey under the network section in that file.
Some examples:- pasta:--map-gw: Allow the container to directly reach the host using the gateway address.
- pasta:--mtu,1500: Specify a 1500 bytes MTU for the tap interface in the container.
- pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp:
disable IPv6, assign
10.0.2.0/24to thetap0interface in the container, with gateway10.0.2.3, enable DNS forwarder reachable at10.0.2.3, set MTU to 1500 bytes, disable NDP, DHCPv6 and DHCP support. - pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp: same as above, but leave the MTU to 65520 bytes
- pasta:-t,auto,-u,auto,-T,auto,-U,auto: enable automatic port forwarding based on observed bound ports from both host and container sides
- pasta:-T,5201: enable forwarding of TCP port 5201 from container to host, using the loopback interface instead of the tap interface for improved performance