-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Communication between containers on separate networks #5805
Comments
No way at present, though I imagine you could add firewall rules manually to restrict networks from reaching each other. I imagine that CNI does have some way of doing this, given its origins in Kube, so that is something else worth researching. |
A friendly reminder that this issue had no activity for 30 days. |
Nope. We should investigate further, though, this sounds like something we should support. |
This is (should be) a function of what you set the |
No. CNI has no way of knowing what you want the network you create to do/not do with respect to other "networks" (e.g. bridges) on the host system. |
@rhatdan I think we'll need another CNI plugin, similar to the dnsname plugin, to do this. |
A friendly reminder that this issue had no activity for 30 days. |
@baude PTAL Seems like something for you. |
@rhatdan i dont think this is something podman should tread into. i think users should have to add fw rules, unless there is something in cni we can flip a bit on. |
It would be nice if they were isolated by default. But yes having CNI implement this would be best. |
This sounds like a security issue. Can we document this in the man page? |
The following iptables commands seem to successfully isolate iptables -A INPUT -i cni-podman1 -j MARK --set-mark 1
iptables -A INPUT -i cni-podman2 -j MARK --set-mark 2
iptables -A FORWARD -o cni-podman1 -m mark --mark 0 -j ACCEPT
iptables -A FORWARD -o cni-podman1 -m mark ! --mark 1 -j REJECT
iptables -A FORWARD -o cni-podman2 -m mark --mark 0 -j ACCEPT
iptables -A FORWARD -o cni-podman2 -m mark ! --mark 2 -j REJECT The number of commands is O(N) where N is the number of the networks (not the number of the containers). I'm planning to implement this as a CNI plugin, but I'd like to get some design review before doing that. RFC. |
Can we make a separate chain in FORWARD for each network? We could have the separate chains default to REJECT which would only require a single ACCEPT rule for each new chain. Keeps the overall FORWARD chain smaller. |
Sorry, a separate chain which FORWARD would transfer to for each network |
It looks like, to enforce isolation between docker networks, docker added two chans: Chain DOCKER-ISOLATION-STAGE-1 Stage 1 has a rule for each bridge sending to somewhere off bridge:
Stage 2 also has rules for all their bridges where the output is another docker created network:
Thus anything from a docker network to another docker network is isolated. As each network is created/removed, these chains are updated. If there is a way for docker (or podman) to explicitly allow network x to talk to network y via run command option, I suspect that they explicitly add ACCEPT rules, probably to stage-2. |
This seems to work as well. |
Implemented as a CNI plugin ( I'm planning to propose this to CNI upstream (https://github.com/containernetworking/plugins). |
Submitted a proposal to CNI upstream: containernetworking/plugins#573 EDIT PR: containernetworking/plugins#584 |
A friendly reminder that this issue had no activity for 30 days. |
@AkihiroSuda Any progress? |
@flouthoc I am looking to dive into some rust/netavark work. @rhatdan @Luap99 you think this would be a good thing to try as a first issue I got here from containers/netavark#154 |
@cdoern Sure, please feel free to take this one. I think this falls more into category of iptables/firewall stuff. |
@cdoern Are you working on this? |
yes @rhatdan containers/netavark#275 is the first step I am about to open a c/common PR for the option handling as well |
Great |
@Luap99 do we need to modify podman to expose this option? |
No but we have to add the option to the network create man page |
This has been fixed upstream. @cdoern can you please verify this? Please close if so. |
yes, a new network option |
We still have to document that in the man page. |
I will do that today, nice catch |
[CI:DOCS] document the podman network create -o=isolate which allows networks to cut themselves off from external connections. resolves containers#5805 Signed-off-by: Charlie Doern <cdoern@redhat.com>
[CI:DOCS] document the podman network create -o=isolate which allows networks to cut themselves off from external connections. resolves containers#5805 Signed-off-by: Charlie Doern <cdoern@redhat.com>
Is communication between rootful containers on separate networks allowed by design? In Docker, containers on separate networks cannot access each other out of the box, whereas here they appear to:
The networks were created with
podman network create <name>
.Is there any way to get the same behaviour as with Docker, where containers cannot reach each other directly in this fashion and instead have to go through published ports on the host?
Output of
podman version
:The text was updated successfully, but these errors were encountered: