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>
Removing content and pointing at the new website as a part of the CNI Documentation migration.
Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com>
Concurrent use of the `portmap` and `firewall` plugins can result in
errors during iptables chain creation:
- The `portmap` plugin has a time-of-check-time-of-use race where it
checks for existence of the chain but the operation isn't atomic.
- The `firewall` plugin doesn't check for existing chains and just
returns an error.
This commit makes both operations idempotent by creating the chain and
then discarding the error if it's caused by the chain already
existing. It also factors the chain creation out into `pkg/utils` as a
site for future refactoring work.
Signed-off-by: Tim Gross <tim@0x74696d.com>
The CNI spec states that for DEL implementations, "when CNI_NETNS and/or
prevResult are not provided, the plugin should clean up as many resources as
possible (e.g. releasing IPAM allocations) and return a successful response".
This change results in the firewall plugin conforming to the spec by not
returning an error whenever the del method is not provided a prevResult.
Signed-off-by: Erik Sipsma <sipsma@amazon.com>
Now that libcni has the ability to print a version message, plumb it
through correctly.
While we're at it,
- fix import paths
- run gofmt
- add some more comments to sample
- add container runtime swappability for release
Example of usage, which uses flannel for allocating IP
addresses for containers and then registers them in `trusted`
zone in firewalld:
{
"cniVersion": "0.3.1",
"name": "flannel-firewalld",
"plugins": [
{
"name": "cbr0",
"type": "flannel",
"delegate": {
"isDefaultGateway": true
}
},
{
"type": "firewall",
"backend": "firewalld",
"zone": "trusted"
}
]
}
Fixes #114
Signed-off-by: Alban Crequy <alban@kinvolk.io>
Signed-off-by: Michal Rostecki <mrostecki@suse.com>
Distros often have additional rules in the their iptabvles 'filter' table
that do things like:
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
docker, for example, gets around this by adding explicit rules to the filter
table's FORWARD chain to allow traffic from the docker0 interface. Do that
for a given host interface too, as a chained plugin.
