Add option --bridge-accept-fwmark#50476
Merged
robmry merged 1 commit intomoby:masterfrom Jul 23, 2025
Merged
Conversation
1279bb9 to
76d9df0
Compare
76d9df0 to
dc66050
Compare
akerouanton
approved these changes
Jul 22, 2025
| // bridge itself). In particular, these are not external interfaces for the purpose of | ||
| // blocking direct-routing to a container's IP address. | ||
| TrustedHostInterfaces []string | ||
| // AcceptFwMark is a firewall mark/mask. Packets will this mark will not be dropped by |
Member
There was a problem hiding this comment.
Suggested change
| // AcceptFwMark is a firewall mark/mask. Packets will this mark will not be dropped by | |
| // AcceptFwMark is a firewall mark/mask. Packets with this mark will not be dropped by |
dc66050 to
5fc7253
Compare
austinvazquez
approved these changes
Jul 22, 2025
Contributor
austinvazquez
left a comment
There was a problem hiding this comment.
LGTM, very well written I had just one question for my own learning. :)
Packets with the given firewall mark are accepted by the bridge driver's filter-FORWARD rules. The value can either be an integer mark, or it can include a mask in the format "<mark>/<mask>". Signed-off-by: Rob Murray <rob.murray@docker.com>
5fc7253 to
cf1695b
Compare
Contributor
Author
|
Updated:
|
austinvazquez
approved these changes
Jul 23, 2025
akerouanton
approved these changes
Jul 23, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
- What I did
For iptables, users can add an
ACCEPTrule to theDOCKER-USERchain - and that rule is final, the packet won't be processed by Docker's other filter-FORWARD rules - so it can be used to skip checks for published ports etc.With nftables, there's no equivalent to the call to
DOCKER-USERchain embedded in Docker's own base chain ... Docker expects to own the whole table, rules added by users to chains in that table will not be preserved. Users can add rules to chains in their own tables, where they can manipulate and drop packets before or after they're processed by Docker's rules.However, an "accept" in one nftables chain is only an accept in the base chain that called the rule. So, if Docker's base chain drops the packet, it'll still do that (regardless of the order in which chains are processed) ... meaning there's no way for a user-managed table to override Docker's "drop".
So, make it possible to configure the daemon with a firewall mark/mask that results in an early "accept" in Docker's filter-FORWARD chain.
(It's possible mark/marks will need to be configurable per-network rather than per-daemon. It can be extended to that if a requirement emerges.)
The format of the option must be as follows, the usual base markers are accepted (including
0xand0o):<mark>- the exact 32-bit unsigned integer mark value to match, or<mark>/<mask>- the packet's mark is masked, then matched against the given mark.Will need to update the CLI's
docs/reference/dockerd.mdwhen this is merged.- How I did it
Add daemon option
--bridge-accept-fwmark.Packets with the given firewall mark/mask are accepted by the bridge driver's filter-FORWARD rules.
The value can either be an integer mark, or it can include a mask in the format
<mark>/<mask>. Mark and mask may include a base prefix (0x1).- How to verify it
- Human readable description for the release notes