feat: add transparent-tunnel CNI mode for GPS VFP enforcement (Linux)#4319
feat: add transparent-tunnel CNI mode for GPS VFP enforcement (Linux)#4319alam-tahmid wants to merge 1 commit intoAzure:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces GlobalPodSecurity configuration plumbing to carry a new boolean knob from CNI network config into endpoint metadata, and updates default CNI conflists to surface the option (defaulting to false).
Changes:
- Added
globalPodSecurityto CNINetworkConfig(JSON) and plumbed it intonetwork.EndpointInfo. - Extended
networkendpoint-related structs to carryGlobalPodSecurity. - Added unit tests for config unmarshalling and
createEpInfopropagation, and updated default Linux/Windows conflists to include the flag (set tofalse).
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
network/endpoint.go |
Adds GlobalPodSecurity fields to endpoint and EndpointInfo structs. |
cni/network/network.go |
Wires NetworkConfig.GlobalPodSecurity into generated EndpointInfo. |
cni/network/network_test.go |
Adds coverage to ensure createEpInfo propagates the flag into EndpointInfo. |
cni/netconfig.go |
Adds GlobalPodSecurity to CNI JSON config (globalPodSecurity). |
cni/netconfig_test.go |
Adds JSON unmarshal tests for globalPodSecurity defaulting/values. |
cni/azure-windows.conflist |
Adds "globalPodSecurity": false to default Windows conflist. |
cni/azure-linux.conflist |
Adds "globalPodSecurity": false to default Linux conflist. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
alam-tahmid
force-pushed
the
tahmidalam/gps-config-plumbing
branch
from
b7af504 to
0d1ce9f
Compare
QxBytes
left a comment
QxBytes
left a comment
There was a problem hiding this comment.
Assuming your iptables changes will be going in the existing transparent client endpoint code, (unless it's a new scenario)? Also assuming this change affects nodesubnet (no azure cns present)?
alam-tahmid
force-pushed
the
tahmidalam/gps-config-plumbing
branch
from
0d1ce9f to
a951bf0
Compare
alam-tahmid
changed the title
alam-tahmid
force-pushed
the
tahmidalam/gps-config-plumbing
branch
2 times, most recently
from
e051e3d to
ecbdd88
Compare
QxBytes
left a comment
QxBytes
left a comment
There was a problem hiding this comment.
Just a note that for transparent-vlan I needed to run something for rp_filter. If you already tested and it works then should be fine but just bringing it to your attention if something pops up in the future.
Also for the ExecuteRawCommand it should be fine since you control the command input but just for future reference.
alam-tahmid
force-pushed
the
tahmidalam/gps-config-plumbing
branch
from
ecbdd88 to
6323fa7
Compare
| // | ||
| // 3. IP rule + route — marked packets are routed via the host's physical | ||
| // interface, which forces them through VFP for NSG enforcement. | ||
| func (client *TransparentTunnelEndpointClient) addGPSTunnelRules() error { |
There was a problem hiding this comment.
lets not use GPS term in CNI code
| if err := client.iptablesClient.InsertIptableRule( | ||
| iptables.V4, iptables.Mangle, iptables.Prerouting, match, "RETURN", | ||
| ); err != nil { | ||
| return errors.Wrapf(err, "failed to insert service CIDR RETURN rule for %s", cidr) |
There was a problem hiding this comment.
can you explain why this is required?
| // 2. Fwmark MARK rule — append so it comes after RETURN rules. | ||
| markMatch := "-i " + hostVeth | ||
| markTarget := "MARK --set-mark " + markStr | ||
| if err := client.iptablesClient.AppendIptableRule( | ||
| iptables.V4, iptables.Mangle, iptables.Prerouting, markMatch, markTarget, | ||
| ); err != nil { | ||
| return errors.Wrap(err, "failed to append GPS fwmark MARK rule") | ||
| } | ||
| logger.Info("GPS: added fwmark MARK rule", | ||
| zap.String("veth", hostVeth), zap.String("mark", markStr)) |
There was a problem hiding this comment.
why do we need iptable rule to mark packet? can we not add ip rule to lookup custome routing table based on pod cidr?
something like this:
ip rule add from 10.9.255.0/24 table 100
ip route add default via 10.9.255.1 dev eth1 table 100
| // the add and tolerate "File exists" errors. This avoids a TOCTOU race where | ||
| // two concurrent pod creates both see the rule missing and both try to add it. | ||
| tableStr := strconv.Itoa(gpsTunnelRouteTable) | ||
| if _, err := client.plClient.ExecuteCommand(context.TODO(), "ip", "-4", "rule", "add", "fwmark", markStr, "lookup", tableStr); err != nil { |
There was a problem hiding this comment.
also lets use netlink apis to do this..
Reason for Change:
Add
transparent-tunnelCNI mode that forces same-node pod-to-pod traffic through the host'sphysical interface (and therefore through VFP) so Azure NSG rules are enforced on intra-node
communication. This implements GPS (GlobalPodSecurity) for Linux using iptables fwmark-based
policy routing, including:
ClusterIP UDP traffic (service CIDR RETURN rules inserted before MARK rule)
pod creates; ref-counted cleanup using real iptables -S output patterns on delete)
Issue Fixed:
Requirements:
Notes:
This is PR 1 of 2 for the GPS feature:
transparent-tunnelmode + Linux iptables/ip-rule implementationThe mode is opt-in via conflist:
"mode": "transparent-tunnel". No behavioral change to existingtransparent or other modes.
Replaces the previous
GlobalPodSecurity: trueboolean flag approach with a dedicated CNI modethat uses Go struct embedding (zero code copy from TransparentEndpointClient).