Reject policies that contain rules with more than one L3 match in a single rule#3015
Conversation
There was a problem hiding this comment.
Do we still need the !l3DependentL4Support[member] check in egress, since all values are false?
There was a problem hiding this comment.
Not strictly, no, but egress label-dependent l4 is pretty close so it seems easy enough to just include this here. It'll require a minor rebase and update for the egress work.
f64dd16 to
a3b27d8
Compare
c7d48fa to
b22db04
Compare
|
test-me-please |
There was a problem hiding this comment.
This will cause ToServices to break, as ToServices rule is being translated into ToCIDRSet rule. This code needs a bit more logic that handles that case.
There was a problem hiding this comment.
Cool. Rather than opening a hole for configuration of things that violate the general rule semantics, I've attempted to reshuffle the sanitization logic so that internally we can represent things in whichever way makes sense, but externally we should only advertise support for particular combinations. This approach is represented by the new patch "daemon: Shift policy sanitize up to handle".
b22db04 to
740a97e
Compare
|
It looks like the reason it fails after that translation is that we have yet another |
740a97e to
d4370ad
Compare
|
Nice! |
d4370ad to
7512be8
Compare
Share more code between these functions. Signed-off-by: Joe Stringer <joe@covalent.io>
Rules should be sanitized relatively early, and in the k8s case they already were sanitized before reaching the repository. Do likewise for the regular API case so that k8s doesn't double-sanitize the rules. This avoids issues when performing translation of k8s rules internally after we've already sanitized and validated rule combinations, where the translated rules no longer satisfy the same constraints as what is rejected at the API - for example, translating headless services policy into CIDR policies. Signed-off-by: Joe Stringer <joe@covalent.io>
7512be8 to
0b2a7ee
Compare
Signed-off-by: Joe Stringer <joe@covalent.io>
Signed-off-by: Joe Stringer <joe@covalent.io>
0b2a7ee to
7cd0d29
Compare
|
test-me-please |
Addressed the issue, please re-review
tgraf
left a comment
There was a problem hiding this comment.
I'm not 100% happy with the validation only happening via the API but this is a great step forward so I'm fine with this for now.
This PR rejects policies which are not supported as per the assessment in #3004 .
The combination of
fromCIDRandfromEndpointswas previously allowed, but conflicted with the standard rules for members in anIngressRuledefined below, so this PR disallows it.cilium/pkg/policy/api/rule.go
Lines 99 to 102 in ca6e1cb
Note that there are certain combinations, like the above, which we have previously accepted policies for and treated as OR (eg,
FromCIDR: xwithFromEndpoints: yin the same rule). These policies must be split into separate rules, one for each L3 after this PR. Examples can be seen in the unit test changes in this PR.