v0.1.6 api review #235
v0.1.6 api review #235
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: astoycos The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
|
/cc |
|
/assign @danwinship @thockin @aojea |
Signed-off-by: astoycos <astoycos@redhat.com>
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
@astoycos: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| // implementation can apply any of the matching policies to the connection, and | ||
| // there is no way for the user to reliably determine which one it will choose. |
There was a problem hiding this comment.
There are some implementations that are able to do this deterministically, I did it sorting by name here https://github.com/kubernetes-sigs/kube-network-policies/blob/db089bc6ed6c17a654ef0ea3f3a93d9122041c4e/pkg/networkpolicy/networkpolicyapi.go#L189-L196
I think we can guide users, and say that from the API point of view is difficult to define the exact behavior as it may depend on implementation details, but they should refer to the project implementing this API to understand what is the expected behavior
There was a problem hiding this comment.
This was hashed out in #216 and #229.
Individual implementations may do something deterministic, but they are not required to. The point of the explanation here is that if you want an "expected behavior", then you have to avoid having two ANPs with the same priority that both match the same packet. (But also, if you do have two ANPs with the same priority that both match the same packet, the "undefined-ness" is much more restricted than it was before; the implementation must obey one of the matching policies. It can't just "always deny", or ignore both policies, etc.)
There was a problem hiding this comment.
I was trying to point out that we can guide the users to ask their implementations about the behaviors, the way is worded now seems that "is impossible to know", when it really means "it is impossible to define a general behavior, but implementations may have a deterministic one"
There was a problem hiding this comment.
What it really means is "don't do that".
The only scenario that is not well-defined is when you have two ANPs at the same priority that attempt to take different actions on the same packet. No matter what the implementation does, it will fail to obey the administrator's intent, because the administrator has requested that it do two contradictory things. Don't do that. Don't ask which policy it's actually going to use in that case, just fix your policies.
There was a problem hiding this comment.
as a developer is clear, but as a user you can do it if the implementation you are using is deterministic
| @@ -130,11 +162,16 @@ type AdminNetworkPolicyIngressRule struct { | |||
| // AdminNetworkPolicyEgressRule describes an action to take on a particular | |||
| // set of traffic originating from pods selected by a AdminNetworkPolicy's | |||
| // Subject field. | |||
| // <network-policy-api:experimental:validation> | |||
| // +kubebuilder:validation:XValidation:rule="!(self.to.exists(peer, has(peer.networks) || has(peer.nodes)) && has(self.ports) && self.ports.exists(port, has(port.namedPort)))",message="networks/nodes peer cannot be set with namedPorts since there are no namedPorts for networks/nodes" | |||
There was a problem hiding this comment.
@thockin I think that you mention this to me at one point, about having a way to unit test or validate these expressions
| // | ||
| // Support: Core | ||
| // | ||
| To []AdminNetworkPolicyEgressPeer `json:"to"` |
There was a problem hiding this comment.
why now the differentiation between Ingress and Egress?
There was a problem hiding this comment.
The network selector was added to egress (egress controls by CIDR block). We didn't include Ingress yet due to the difficulties reliably determining the source IP of ingress traffic.
https://network-policy-api.sigs.k8s.io/npeps/npep-126-egress-traffic-control/#non-goals
| // To be selected a Namespace must have all of the labels defined in SameLabels, | ||
| // AND they must all have the same value as the subject of this policy. | ||
| // If Samelabels is Empty then nothing is selected. | ||
| Namespaces *metav1.LabelSelector `json:"namespaces,omitempty"` |
What type of PR is this?
/kind api-change
What this PR does / why we need it:
This PR is a diff of /apis from v0.1.6 (main branch) to v0.1.1 (release-v0.1.1 branch).
Note: This PR is purely to facilitate review, it is not intended to merge.
Note2: This does not include FQDN support from from @rahulkjoshi in #233, which will come in our next 0.2.0 release