genpolicy: support AddARPNeighbors #11663
Merged
Conversation
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
When the network interface provisioned by the CNI has static ARP table entries, the runtime calls AddARPNeighbor to propagate these to the agent. As of today, these calls are simply rejected. In order to allow the calls, we do some sanity checks on the arguments: We must ensure that we don't unexpectedly route traffic to the host that was not intended to leave the VM. In a first approximation, this applies to loopback IPs and devices. However, there may be other sensitive ranges (for example, VPNs between VMs), so there should be some flexibility for users to restrict this further. This is why we introduce a setting, similar to UpdateRoutes, that allows restricting the neighbor IPs further. The only valid state of an ARP neighbor entry is NUD_PERMANENT, which has a value of 128 [1]. This is already enforced by the runtime. According to rtnetlink(7), valid flag values are 8 and 128, respectively [2], thus we allow any combination of these. [1]: https://github.com/torvalds/linux/blob/4790580/include/uapi/linux/neighbour.h#L72 [2]: https://github.com/torvalds/linux/blob/4790580/include/uapi/linux/neighbour.h#L49C20-L53 Fixes: kata-containers#11664 Signed-off-by: Markus Rudy <mr@edgeless.systems>
danmihai1
reviewed
Aug 12, 2025
| @@ -347,6 +347,14 @@ | |||
| "^127\\.(?:[0-9]{1,3}\\.){2}[0-9]{1,3}$" | |||
| ] | |||
| }, | |||
| "AddARPNeighborsRequest": { | |||
| "forbidden_device_names": [ | |||
| "lo" | |||
There was a problem hiding this comment.
@burgerdev, thanks for looking into this!
Do you think forbidden_device_names for both AddARPNeighborsRequest and UpdateRoutesRequest should specify regex values instead of the full interface names?
Users might not need the flexibility of regex, but I guess some of them might want to specify as forbidden:
"^.*$", or
"^eth[0-9]+$", or even
"^lo0?$"
danmihai1
approved these changes
Aug 13, 2025
Redent0r
approved these changes
Aug 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When the network interface provisioned by the CNI has static ARP table entries, the runtime calls
AddARPNeighborto propagate these to the agent. As of today, these calls are simply rejected.In order to allow the calls, we do some sanity checks on the arguments.
We must ensure that we don't unexpectedly route traffic to the host that was not intended to leave the VM. In a first approximation, this applies to loopback IPs and devices. However, there may be other sensitive ranges (for example, VPNs between VMs), so there should be some flexibility for users to restrict this further. This is why we introduce a setting, similar to
UpdateRoutes, that allows restricting the neighbor IPs further. Note that reverting back to the existing "deny all ARP neighbours" behaviour is as simple as forbidding IP.*.Forbidding ARP entries for loopback IPs is mostly defence-in-depth - these should be rejected/ignored by the kernel!
The only valid state of an ARP neighbor entry is
NUD_PERMANENT, which has a value of128. This is already enforced by the runtime.According to
rtnetlink(7):These values are 8 and 128, respectively, thus we allow any combination of these (
128 | 8 == 136).