
This syntax was used prior to 4.0 and is still supported for backwards compatibility. Fixes #19089 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
6.4 KiB
####> This option file is used in: ####> podman create, kube play, pod create, run ####> If file is edited, make sure the changes ####> are applicable to all of those.
--network=mode, --net
Set the network mode for the <<container|pod>>.
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.
-
ip=IPv6: Specify a static ipv6 address for this container.
-
mac=MAC: Specify a static mac address for this container.
-
interface_name: Specify a name for the created network interface inside the container.
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. Using the network name implies the bridge network mode. 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 networks comma separated 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: Do not create a network namespace, the container uses the host's network. Note: The host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
-
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 slirp4netns for rootless ones.
-
slirp4netns[:OPTIONS,...]: use slirp4netns(1) to create a user network stack. This is the default for rootless containers. It is possible to specify these additional options, they can also be set with
network_cmd_options
in containers.conf:- allow_host_loopback=true|false: Allow slirp4netns to reach the host loopback IP (default is 10.0.2.2 or the second IP from slirp4netns cidr subnet when changed, see the cidr option below). The default is false.
- mtu=MTU: Specify the MTU to use for this network. (Default is
65520
). - cidr=CIDR: Specify ip range to use for this network. (Default is
10.0.2.0/24
). - enable_ipv6=true|false: Enable IPv6. Default is true. (Required for
outbound_addr6
). - outbound_addr=INTERFACE: Specify the outbound interface slirp binds to (ipv4 traffic only).
- outbound_addr=IPv4: Specify the outbound ipv4 address slirp binds to.
- outbound_addr6=INTERFACE: Specify the outbound interface slirp binds to (ipv6 traffic only).
- outbound_addr6=IPv6: Specify the outbound ipv6 address slirp binds to.
- port_handler=rootlesskit: Use rootlesskit for port forwarding. Default.
Note: Rootlesskit changes the source IP address of incoming packets to an IP address in the container network namespace, usually
10.0.2.100
. If the application requires the real source IP address, e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for rootless containers when connected to user-defined networks. - port_handler=slirp4netns: Use the slirp4netns port forwarding, it is slower than rootlesskit but preserves the correct source IP address. This port handler cannot be used for user-defined networks.
-
pasta[:OPTIONS,...]: use pasta(1) to create a user-mode networking stack.
This is 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. If port forwarding isn't configured, ports are forwarded dynamically as services are bound on either side (init namespace or container namespace). 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).
Also, -t none and -u none are passed if, respectively, no TCP or UDP port forwarding from host to container is configured, 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.
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,
equivalent to default slirp4netns(1) options: disable IPv6, assign
10.0.2.0/24
to thetap0
interface 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, equivalent to default slirp4netns(1) options with Podman overrides: 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
NOTE: For backward compatibility reasons, if there is an existing network named
pasta
, Podman uses it instead of the pasta mode."?