-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. 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/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for putting this together @rahulkjoshi !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall
/lgtm for the user stories! I'll let @danwinship Add the approval here when he's ready |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the implementation of this spec expected to maintain the list of resolved IPs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that's the expectation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the API(s) that support this NPEP define the expectations for managing the list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rahulkjoshi do you have any feedback regarding ^?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is all other egress denied, including in-cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 AdminNetworkPolicyEgressPeer
s 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue-Tracker: #133