NPEP: FQDN Selector for Egress, User stories#134
Conversation
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi @rahulkjoshi. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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/test-infra repository. |
npinaeva
left a comment
There was a problem hiding this comment.
thanks for putting this together @rahulkjoshi !
astoycos
left a comment
There was a problem hiding this comment.
Good start, thanks for opening this! This NPEP is narrow and I'm alright with that :)
I think in the case where we may not have a bunch of proper user stories to add, but still want to specify the explicit desired use of a single user story examples can be used to add explicit color.
i.e in this case there's really only one real desire .... add a FQDN selector to ANP + BANP however if we want to specify that the selector will include both matching by full name AND by wildcard pattern let's use examples on that single user story to do so.
|
Restored branch |
|
/cc |
319cec0 to
5bcb5b5
Compare
|
/lgtm for the user stories! I'll let @danwinship Add the approval here when he's ready |
astoycos
left a comment
There was a problem hiding this comment.
Oh an additionally @rahulkjoshi Please add this to NPEP to the website https://github.com/kubernetes-sigs/network-policy-api/blob/main/mkdocs.yml#L58
eaf7f9a to
afdec78
Compare
dacf43d to
970076e
Compare
|
/lgtm |
| resolve to. Keeping up with changing IP addresses is a maintenance burden, and | ||
| hampers the readability of the network policies. |
There was a problem hiding this comment.
Is the implementation of this spec expected to maintain the list of resolved IPs?
There was a problem hiding this comment.
Yes that's the expectation.
There was a problem hiding this comment.
Will the API(s) that support this NPEP define the expectations for managing the list?
There was a problem hiding this comment.
@rahulkjoshi do you have any feedback regarding ^?
There was a problem hiding this comment.
We will probably do some work to define expected behaviors alongside the API. I will try to flesh those out in a follow-up as well, but as some prior art of what I'm thinking: https://docs.google.com/document/d/1wOO6fgY0PRToJ85yC5WFDywAhwkK0m-ynLrHW-EmuGM/edit#bookmark=id.61oxh3gwesyg
| (for example `kubernetes.io`). | ||
| * Support basic wildcard matching capabilities when specifying FQDNs (for | ||
| example `*.cloud-provider.io`) | ||
| * Currently only `ALLOW` type rules are proposed. |
There was a problem hiding this comment.
Is all other egress denied, including in-cluster?
There was a problem hiding this comment.
Not exactly -- AdminNetworkPolicy doesn't operate on default deny semantics like that.
These rules would be paired with either a lower priority DENY rule, or use the default deny behavior of Kubernetes NetworkPolicy.
There was a problem hiding this comment.
@rahulkjoshi ^ is what I thought but the NPEP is not explicit in this regard. Might be worth adding a condensed form of ^ to be explicit.
There was a problem hiding this comment.
These rules would be paired with either a lower priority DENY rule...
However, the NPEP states that DENY rules are not supported.
There was a problem hiding this comment.
Yeah I can see how that's confusing -- I hope long-term it's clearer when we provide the API but, I'll try to explain and I'm open to suggestions on how to phrase this so it's easier to understand for other readers:
Quick Note, API details will be affected by what we decide in #144
Roughly speaking, the new API will extend the AdminNetworkPolicyEgressPeer by adding a new selector. AdminNetworkPolicyEgressPeer is specified inside the AdminNetworkPolicyEgressRule struct (in the repeated field To).
When we say DENY rules are not supported, more specifically what we're saying is: If a AdminNetworkPolicyEgressRule has Action: "Deny", then none of the AdminNetworkPolicyEgressPeers in that rule can specify FQDN Selectors.
You can however, specify another AdminNetworkPolicyEgressRule with Action: "Deny" (you can either make another entry in AdminNetworkPolicySpec.Egress or create a separate ANP object) and include other selectors in that rule.
|
Small poke @rahulkjoshi This seems pretty close! |
There was a problem hiding this comment.
/lgtm
/approve
Thanks for all the hard work @rahulkjoshi!!!
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: astoycos, rahulkjoshi The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue-Tracker: #133