Add allowedsourceprefixes ebpf #11615
Conversation
marvin-tigera
added
release-note-required
|
|
…an/calico into add-allowedsourceprefixes-ebpf
| CALI_DEBUG("Workload RPF check src=" IP_FMT " skb iface=%d.", | ||
| debug_ip(ctx->state->ip_src), ctx->skb->ifindex); | ||
| if (!r) { | ||
| if (!r && !cali_allowsource_lookup(&ctx->state->ip_src, ctx->skb->ifindex)) { |
There was a problem hiding this comment.
This would only work for IPs that are not assigned to any other pod. If the IP is assigned to anything else that exists in the cluster (host or pod), you would have a route and your secondary check would not execute. But the RPF check would fail below because it would not be a local pod with the same interface index as your current endpoint.
There was a problem hiding this comment.
If you only want to make it for IPs that are not part of the cluster, wouldn't it be easier to add a route to the bpf routes with the ifindex of this pod an then you would have a match, thus you would have a route and it all would work without any changes to the bpf code?
You would need to add logic to the bpf_routes_mgr to add the route, preferable to changing the bpf code.
If you need to allow IPs that may exist in the cluster, I think that would be also achievable via those routes, but that woudl require changes in many other places.
There was a problem hiding this comment.
@tomastigera do we have the same constraint in iptables based implementation of allowed source prefixes? Does that only work for cluster-external IPs?
I've also been in touch with @sridhartigera regarding this, tagging him here for visibility.
There was a problem hiding this comment.
@tomastigera do we have the same constraint in iptables based implementation of allowed source prefixes? Does that only work for cluster-external IPs?
I've also been in touch with @sridhartigera regarding this, tagging him here for visibility.
@tomastigera As far as using route map is concerned, I am not sure if its a good fit as we can have multiple pods annotated with same spoof addresses.
| @@ -0,0 +1,99 @@ | |||
| package allowsources | |||
There was a problem hiding this comment.
allowsource is a very specific name. Could you think of a broader usecase?
6 participants
Description
This PR adds support for allowedSourcePrefixes annotation to Calico with eBPF mode. This annotation allows the pods to sent out traffic with a source IP other than the pod IP and the annotation is already implemented for non-eBPF Calico modes.
Calico node is the only component that is affected directly by the PR. However, there are changes at the eBPF layer that can affect traffic in the cluster.
The testing consisted of a TCP packet generating script and a UDP proxy with IP_TRANSPARENT option enabled. The testing setup will be detailed below, but the results are common for both manual tests.
TCP Packet Generation
A pod controlled by a DaemonSet running on one of the nodes generates empty TCP packets using Python & Scapy. The source IP is set to 192.192.192.192. The generated packets are sent to an external machine every second. A tcpdump instance is running on the target machine.
UDP Proxy
A simple Python script that acts as a UDP proxy is deployed to the cluster with the updated calico-node image as a DaemonSet. Python script accepts incoming packets and uses IP_TRANSPARENT option to send them to the external machine while preserving the source IP. Once again, tcpdump is running on the target machine to observe incoming packets
Results
In both cases, before adding any annotations to the test pod, the egress pods are getting dropped and the following logs are observed in
bpftool prog tracelogSecond line was added temporarily for debugging purposes
Once the following annotation
cni.projectcalico.org/allowedSourcePrefixes: '["192.192.192.192/32"]'is added to the test pod, packets start reaching target machine. In addition, the following logs are observed.Once the annotation is removed, the initial logs are observed again.
Related issues/PRs
Fixes #11591
Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.