-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
datapath: Cover subnet encryption in XFRM leak test #27212
Conversation
This commit complements 27a8fb1 ("datapath: Integration test for XFRM leaks on node churn"). In that previous commit, subnet encryption (the XFRM config used for ENI and Azure IPAM modes) was not covered. This commit covers it. There are two pre-conditions to subnet encryption: nodes must have a list of pod subnets (cf. IPv{4,6}PodSubnets) and the encryption interface must exist and have an IP address. The test configures these two preconditions before running the usual checks for XFRM config leaks. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to confess that I didn't know encryption interface before, but my initial understanding is:
- it's used for non-tunneling mode, replacing the cilium_vxlan.
- it's used for EKS because of its special IPAM mode: node IPs are within the pod CIDRs, so we don't need tunnels, but consequently we need to specify encryption interface.
In the test, encryption iface's address is 1.1.1.1, but pod subnet is 4.4.0.0/16. If my understanding is correct, maybe we should assign a IP address within the pod CIDR to encrption interface?
It's actually a bit simpler: it's just the native device from which encrypted traffic will leave. Typically some eth0 interface. On EKS and AKS, if
It is therefore expected that the IP address of that eth0 interface isn't part of the pod subnet. |
@pchaigno I am a bit puzzled about this PR - did you intend to add a new test case, or to replace the existing one to cover the subnet encryption? AFAICS, the latter was done. |
This commit complements 27a8fb1 ("datapath: Integration test for XFRM leaks on node churn"). In that previous commit, subnet encryption (the XFRM config used for ENI and Azure IPAM modes) was not covered. This commit covers it.
There are two pre-conditions to subnet encryption: nodes must have a list of pod subnets (cf.
IPv{4,6}PodSubnets
) and the encryption interface must exist and have an IP address. The test configures these two preconditions before running the usual checks for XFRM config leaks.