Add libraries for API CIDR string to labels / IPNet#3909
Add libraries for API CIDR string to labels / IPNet#3909ianvernon merged 3 commits intocilium:masterfrom
Conversation
|
test-me-please |
|
Unit tests failed because it relies on the types introduced in #3883, but this can still be reviewed. |
afe5760 to
bbe1b23
Compare
There was a problem hiding this comment.
Since we have "except" in the CIDR definitions for policies, is it possible we would return too few most-specific-CIDR ranges when using this for a policy/identity print? (It should be fine if used on an endpoint, I think). I think you mention this in #3835 but I'm not sure that I fully understand the interactions here and what is left to be pulled in.
If the above can happen, and is a problem, I think we can sort it out by making cidr a list, and then check element in it for ones > prefixLength and also cidr[i].Contains(ipnet). If it matches none add it to the list, if it matches one, override it (so, overwrite an entry in cidr if ipnet is more specific than that entry but add a new entry to cidr if ipnet is outside the range of all the current most specific ranges)
There was a problem hiding this comment.
My expectation (and maybe there's a place this can be left somewhere as a comment) is that CIDR exceptions will be expanded when rendering into labels, so you would end up with, for example,
One rule that uses CIDRSet with exception like:
CIDR: 0.0.0.0/0 Except 0.0.0.0/2
turns into two prefixes, with labels:
cidr:0.0.0.0/0, cidr:128.0.0.0/1
and
cidr:0.0.0.0/0, cidr:0.0.0.0/1, cidr:64.0.0.0/2
In these cases, when attempting to get the printable model, it's redundant to print 0.0.0.0/0 for any of these CIDRs, because of course all CIDRs fall under the default prefix. For the latter example, it's not useful to show 0.0.0.0/1 because cidr:64.0.0.0/2 is naturally within the 0.0.0.0/1, so it's more specific to show cidr:64.0.0.0/2.
Does that help to explain?
7a07389 to
e8aff31
Compare
Signed-off-by: Joe Stringer <joe@covalent.io>
Although identities may contain multiple CIDR labels, it's difficult to read and provides no additional information beyond the longest CIDR in the labels list. Filter through and only print the longest cidr. Signed-off-by: Joe Stringer <joe@covalent.io>
Signed-off-by: Joe Stringer <joe@covalent.io>
e8aff31 to
d7a9ca5
Compare
|
test-me-please |
[Split out from #3835 for easier review]
This PR introduces the library code for #3835 which allows a CIDR rule or CIDRSet rule from the API to be converted into one of two formats:
Labels[]*net.IPNetLabels
Allow conversion into a set of native
Labels(pkg/labels/) that represent the CIDR and all CIDRs that contain it, ie ones with the same prefix but shorter prefix lengths. These are used to allocate an identity, which, when anEndpointSelectoris created on the CIDR prefix, or any prefix that the CIDR falls under, will be selected. This works by, for instance, for10.0.0.0/8creating labels such as:Now, if an
EndpointSelectoris created to match0.0.0.0/0, for instance, it will match this identity. This is what one might expect - the0.0.0.0/0CIDR matches all traffic.IPv6 addresses are handled a bit specially. Labels are not allowed to contain
:, however regular IPv6 formatting per RFC5952 typically contains this character. This PR represents such CIDRs using a label that replaces:with-. The-is converted back before formatting to string. Furthermore, label keys used forEndpointSelectors cannot begin or end with a-, so if the IPv6 CIDR label would otherwise begin or end with with-, eg::/0->--/0, then insert a zero at the start or end to satisfy theEndpointSelectorconstraints. So::/0becomescidr:0--0/0.Finally, although the identities generated using these labels would contain labels for each CIDR Prefix that is in the rule plus every CIDR prefix that is shorter, it is both redundant and too verbose to print these regularly in output such as
cilium identity get. This PR adds a patch to represent such CIDRs with just the most-specific CIDR when formatting. Usingcilium identity get --jsonwill provide the actual underlying information.[]*net.IPNetPR #3835 will also need to create CIDR -> Identity mappings in the ipcache. These are currently managed using
net.IPas they only cover IP addresses. It makes sense to use the native go type*net.IPNetto represent prefixes there. Therefore this PR introduces libraries to also convert the API CIDR rule / CIDRSet rules into slices of*net.IPNetfor insertion into the IPCache.This change is