/cc @andrewsykim @jayunit100 @rikatz

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

We are actively working on a proposal for this and a KEP should be submitted for review soon.

/remove-lifecycle stale

can you post a link to the ongoing design work in here @abhiraut ?

https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/edit#slide=id.g338ac0a8b6_0_48

/lifecycle active

@thockin you can find the KEP here -> #2522
I now updated this issue with the KEP link as well.

Update from 6/10/21 sig-network meeting:

• Get reviews from sig-network folks on user stories -> https://github.com/kubernetes-sigs/network-policy-api/pulls (added some folks on individual PRs)
• Need to close on some fundamental disagreements:
  -- IPBlock (external traffic; original source IP or follow NetworkPolicy v1)
  -- DNP CRD to solve weak (default) security rules or pick one of the alternatives suggested in the KEP
  -- Allow, Deny with Exceptions (authorize) model works for everyone? or Priority based or NP like whitelist

Most recent commits address the following:

Update in semantics from Authorize to Empower (no longer allowed but rather bypasses the Deny as exceptions)
updates to user stories
updates to Namespaces struct to include matching strategies -> Self, SameLabels; Selector
updates to KEP timelines/milestones

Key outstanding issues:

IPBlock external traffic -> we shall discuss this in sig-network for all things Netpol
Get feedback on `Empower`, `Deny` and `Allow` actions for CNP
Is "namespace user CAN override cluster admin rules" a valid use case to solve with this KEP? If yes, is DNP CRD overkill or we want to explore the alternatives suggested with a single CRD.

For the record: this is NOT flagged for 1.23

updated release targets

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

Not really release-locked (yet?)

should we track this somewhere else @thockin? How did gateway-api go about this?

Status: waiting on implementations. It's all out-of-tree so no milestone needed yet?

Hello All. I am interested in using the AdminNetworkPolicy. I see that its status is "frozen". What does this mean in practice? Is it something I can use and rely on for the future? Thanks!

Hello All. I am interested in using the AdminNetworkPolicy. I see that its status is "frozen". What does this mean in practice? Is it something I can use and rely on for the future? Thanks!

the v1alpha1 API for ANP is here: https://github.com/kubernetes-sigs/network-policy-api ; anyone can use it provided the CNI implements it.

@thockin I think we should close this issue, since AdminNetworkPolicy is being implemented and tracked out of tree at https://github.com/kubernetes-sigs/network-policy-api

I have been meaning to figure out how we want to track it. Happy to close this.

Is there another issue in https://github.com/kubernetes-sigs/network-policy-api where we can easily watch for updates on this? I'm very interested in this effort and it would be good to have a centralized place where I can get email updates as progress occures.

@aauren sync wiht @astoycos and @tssurya and @npinaeva , they have periodic meetings and there is also a slack channel

@aauren : Added you to slack channel.. let us know if you have any questions. Also see https://network-policy-api.sigs.k8s.io/

Thank you!