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
docker does not respect previously setup FORWARD rules #29184
Comments
Have you tried inserting your rule in the |
Thanks @aboch --
|
@konradkonrad Yes this is known. Any rule in a docker created chain won't rules won't survive a docker restart. Ideally we'd need to add a chain where users can add their rules and not flush them at daemon start. |
The original issue reporting this behavior/feature request in regarding to user defined rules is #24848 |
Yeah, this is unfortunate. In my opinion it must be possible to configure firewall policies in way that persists docker operations/restarts.
Well either this, or, as a potentially quicker solution, docker could respect certain My policy would now become:
And I would docker expect to only insert below the last mention of the comment I don't know how to feel about using comments for any sort of flow control, but since docker is rather intrusive towards the |
Is there a hope of fixing this issue? This is... really frustrating, and makes restricting access to ports exposed by containers really really difficult. |
Allow users to configure firewall policies in way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-FORWARD-TOP filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby/issues/29184 Fixes moby/moby/issues/23987 Related to moby/moby/issues/24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
@delfuego Yes! I have created a pull request to fix it. |
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby/moby#29184 Fixes moby/moby#23987 Related to moby/moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
woohoo :) 👍 |
Reopening for now, because moby/libnetwork#1675 was not yet vendored in this repository, so the code is not in use yet |
Docker 17.06 (through commit 46392f2, which is part of #32981) includes a change to libnetwork (thanks @wenjianhn) that allows setting up a custom |
Allow users to configure firewall policies in a way that persists docker operations/restarts. Docker will not delete or modify any pre-existing rules from the DOCKER-USER filter chain. This allows the user to create in advance any rules required to further restrict access from/to the containers. Fixes moby#29184 Fixes moby#23987 Related to moby#24848 Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
Description
I'm trying to restrict outgoing connections from inside a container. From what I gathered, outgoing container traffic is routed via the
FORWARD
chain ofiptables
. The problem is, that after restarting the docker service or creating the container, docker will prepend its rules in theFORWARD
chain, so my policy is never matched.Steps to reproduce the issue:
10.0.0.0/8
from thebr-do
bridge device used for the docker network so thatiptables --list FORWARD -v
readsservice docker restart
Describe the results you received:
After restarting the docker daemon, the
FORWARD
chain will be altered in the following way:Outgoing traffic on will now be
ACCEPT
ed before matching my intended policy.Describe the results you expected:
I would have expected that docker adds the
FORWARD
rules more sensibly, or appends them to the end of theFORWARD
chain, so my intended policy stays active.Additional information you deem important (e.g. issue happens only occasionally):
I understand that it is complex for docker to pick the right behavior here. However, there must be a sensible way to enforce system wide policies without going the
DOCKER_OPTS=--iptables=false
route.Output of
docker version
:Output of
docker info
:Running on a physical box.
The text was updated successfully, but these errors were encountered: