Akihiro Suda 22dd6c553d firewall: support ingressPolicy=(open|same-bridge) for isolating bridges as in Docker
This commit adds a new parameter `ingressPolicy` (`string`) to the `firewall` plugin.
The supported values are `open` and `same-bridge`.

- `open` is the default and does NOP.

- `same-bridge` creates "CNI-ISOLATION-STAGE-1" and "CNI-ISOLATION-STAGE-2"
that are similar to Docker libnetwork's "DOCKER-ISOLATION-STAGE-1" and
"DOCKER-ISOLATION-STAGE-2" rules.

e.g., when `ns1` and `ns2` are connected to bridge `cni1`, and `ns3` is
connected to bridge `cni2`, the `same-bridge` ingress policy disallows
communications between `ns1` and `ns3`, while allowing communications
between `ns1` and `ns2`.

Please refer to the comment lines in `ingresspolicy.go` for the actual iptables rules.

The `same-bridge` ingress policy is expected to be used in conjunction
with `bridge` plugin. May not work as expected with other "main" plugins.

It should be also noted that the `same-bridge` ingress policy executes
raw `iptables` commands directly, even when the `backend` is set to `firewalld`.
We could potentially use the "direct" API of firewalld [1] to execute
iptables via firewalld, but it doesn't seem to have a clear benefit over just directly
executing raw iptables commands.
(Anyway, we have been already executing raw iptables commands in the `portmap` plugin)

[1] https://firewalld.org/documentation/direct/options.html

This commit replaces the `isolation` plugin proposal (issue 573, PR 574).
The design of `ingressPolicy` was discussed in the comments of the withdrawn PR 574 ,
but `same-network` was renamed to `same-bridge` then.

Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
2022-02-03 15:49:43 +09:00
2022-01-19 18:23:45 +01:00
2022-01-19 18:23:45 +01:00
2022-01-19 18:24:47 +01:00
2018-09-21 00:34:07 +08:00
2020-12-09 17:46:25 +01:00
2018-10-11 16:15:24 +01:00
2022-01-19 18:24:47 +01:00
2017-03-10 16:46:52 +01:00
2021-05-21 13:13:36 +00:00
2017-07-11 13:57:49 -07:00
2020-12-09 17:46:25 +01:00

test

Plugins

Some CNI network plugins, maintained by the containernetworking team. For more information, see the CNI website.

Read CONTRIBUTING for build and test instructions.

Plugins supplied:

Main: interface-creating

  • bridge: Creates a bridge, adds the host and the container to it.
  • ipvlan: Adds an ipvlan interface in the container.
  • loopback: Set the state of loopback interface to up.
  • macvlan: Creates a new MAC address, forwards all traffic to that to the container.
  • ptp: Creates a veth pair.
  • vlan: Allocates a vlan device.
  • host-device: Move an already-existing device into a container.

Windows: Windows specific

  • win-bridge: Creates a bridge, adds the host and the container to it.
  • win-overlay: Creates an overlay interface to the container.

IPAM: IP address allocation

  • dhcp: Runs a daemon on the host to make DHCP requests on behalf of the container
  • host-local: Maintains a local database of allocated IPs
  • static: Allocate a static IPv4/IPv6 addresses to container and it's useful in debugging purpose.

Meta: other plugins

  • tuning: Tweaks sysctl parameters of an existing interface
  • portmap: An iptables-based portmapping plugin. Maps ports from the host's address space to the container.
  • bandwidth: Allows bandwidth-limiting through use of traffic control tbf (ingress/egress).
  • sbr: A plugin that configures source based routing for an interface (from which it is chained).
  • firewall: A firewall plugin which uses iptables or firewalld to add rules to allow traffic to/from the container.

Sample

The sample plugin provides an example for building your own plugin.

Contact

For any questions about CNI, please reach out via:

If you have a security issue to report, please do so privately to the email addresses listed in the OWNERS file.

S
Description
Some reference and example networking plugins, maintained by the CNI team.
Readme Apache-2.0
20 MiB
Latest
2024-12-02 17:06:11 +01:00
Languages
Go 99.7%
Shell 0.3%