We don't currently support specifying policies that have both "FromCIDR" and "ToPorts" on ingress. This should allow only traffic that matches both of these conditions, and would only apply to traffic that does not originate from another Cilium-managed endpoint.
This is the equivalent issue to #1684, but for ingress.
The interesting thing about ingress is that in many cases (most commonly nodeport with k8s), we lose the source IP address before traffic reaches Cilium, so the CIDR policy would only apply to the source address of the host which the traffic is masqueraded to. Note that CIDR policy does not apply to traffic received from another pod managed by Cilium, so this functionality would not be particularly useful in this scenario.
UPDATE 2019/06/03: With v1.6 providing BPF-based nodeport which does not require obscuring the original IP address, this feature may become more interesting.
That said, even for this case, it could potentially shift some complexity for CIDR handling from the bpf_lxc program to the bpf_netdev program, which would free up some BPF instruction count for use by other features.
In cases of direct routing it may be useful to be able to perform CIDR-dependent ingress L4 policies, as in this case we should still have access to the original source.
Tasks:
Follow-up
We don't currently support specifying policies that have both "FromCIDR" and "ToPorts" on ingress. This should allow only traffic that matches both of these conditions, and would only apply to traffic that does not originate from another Cilium-managed endpoint.
This is the equivalent issue to #1684, but for ingress.
The interesting thing about ingress is that in many cases (most commonly nodeport with k8s), we lose the source IP address before traffic reaches Cilium, so the CIDR policy would only apply to the source address of the host which the traffic is masqueraded to. Note that CIDR policy does not apply to traffic received from another pod managed by Cilium, so this functionality would not be particularly useful in this scenario.
UPDATE 2019/06/03: With v1.6 providing BPF-based nodeport which does not require obscuring the original IP address, this feature may become more interesting.
That said, even for this case, it could potentially shift some complexity for CIDR handling from the
bpf_lxcprogram to thebpf_netdevprogram, which would free up some BPF instruction count for use by other features.In cases of direct routing it may be useful to be able to perform CIDR-dependent ingress L4 policies, as in this case we should still have access to the original source.
Tasks:
bpf_netdev, propagate these identities through to ingressbpf_lxclogicFollow-up