-
Notifications
You must be signed in to change notification settings - Fork 33
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-230: Add dry-run mode. #276
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Nadia Pinaeva <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: npinaeva The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
||
## Goals | ||
|
||
A dry-run mode should not affect any connections, and allow the networking plugin to provide feedback |
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.
Let's be more clear on this:
- A NetworkPolicy object in dry-run mode will not enforce any K8s network policy semantics e.g. it should be treated as if it did not exist. Controllers are free to interpret the contents of the object for purposes of observability/debugging however.
|
||
## TLDR | ||
|
||
Add dry-run mode for (B)ANP to allow "disabling" policies without deleting them. |
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.
Why is this not also a proposal for NetworkPolicy itself?
## References | ||
|
||
Similar features: | ||
- calico: https://docs.tigera.io/calico-cloud/network-policy/staged-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.
I talked to the folks that designed Calico's staged policy and I asked why we added a second resource type StagedNetworkPolicy
instead of an "enforced" flag. The answer was that it allows for staging a change to an existing policy as well as staging a completely new policy. You can have a staged network policy with name "foo" and order 123 as well as an unstaged one with the same name and order. Then the staged version should replace the active one when simulating the upcoming policy verdict.
That's not quite the same as creating a second policy at the same order with a different name; it wouldn't be clear if the user is asking us to simulate both policies being present or only the new one.
Tracking issue #230