Netpol WG update... what should we deliver...and how/when?

[jay vyas]

Hi folks.    Just thought id post on update of where we've been, and some questions about what we should do next.      Basically this communique. has 2 goals.

1) Get a  1st deliverable with a timeline in mind. After we deliver something, IMO we can revise our meeting cadence and role in the broader sig.  

2) Summarize where we're at and get opinions on what we should aim for as a concrete , next deliverable.

3) Open up the floor in case anyone wants to help lead this group, or get more involved.  Although I think a small number of us started it, I think were  really open for anyone to be an owner and get involved at any level.   

- about 3.5 months ago we started meeting every wk to figure out how NetworkPolicy's  might evolve, sparked from a mailing list thread between me, Andrew, Dan, and many others.  Specifically, Dan (Winship's) quote , roughly, was 'In V2... we might do it different' :).

- Since then we've basically had 2 types of user stories: Making the API easier to use (i.e. getting rid of 'sharp edges', to quote mike spreitzer, and adding new semantic functionality to the API for things like Nodes, Services, Namespaces, and so on).

At a high level: Making things easier for administrators with things like overrides and global defaults, and making the API more declarative (service and namespace boundary definitions for policies), node policies, seems to be pretty well agreed upon.

At a lower level: Its very tricky to know what to do next in my opinion.

In any case , here's a  timeline of how things. have evolved in the NetworkPolicy++ WG.

4-15/2020  0) started with this whole idea/conversation of getting a v2 group goin.

5/1/2020 1) Our original 'dumping ground' for all user stories, mostly unfiltered, is here https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/edit.    These stories are a little quirky , but they represent peoples deepest network policy desires, so I think it has intrinsic value in its current state.

7/15/2020 2) Having roughly reached an informal consensus, a small group of us (pre-WG) created https://docs.google.com/spreadsheets/d/1_7QD4LhyfDnItjWoGJkqHVC_Nm76l557tMMjVlmPFFQ/edit#gid=0  to track votes.

7/25/2020 3) Andrew, Tim, Casey, helped us become an official working group, and we had about 4 ensuing meetings getting the community caught up over the next few weeks.

8/1/2020 4) Dan had a eureka moment and summarized our policies into the following document which roughly outlines a plan of action 

https://docs.google.com/document/d/10t4q5XO1ED2PnK3ishn4y3G4Tma7uMYgesG-itQHMiU/edit?ts=5f25f6e7# 

8/15/2020 5) We tableized dave's document into a list of use cases, ordered by dan's groupings, with 1 at the top - and several scalar attributes to quantify the attributes of the user stories (i.e. is it an API change, is it compatible with V1, does it improve usability, do providers want to do it, ... and so on)... https://docs.google.com/spreadsheets/d/1j-0-S01hNy4ZA-nff8sMGO3Gm2EYyGUPpxZhzkvy1r4/edit#gid=0 .  

 

Ok ! so... WHATS NEXT ?

 

so... with new ideas ramping down and us mostly going into clerical mode - I think its time to ask ourselves what were going to deliver and when so we can focus in our meetings and get to a endpoint point for , what we can call "phase 1" of this whole effort.  So, ... what should we deliver here? And when?   

...possible things we can deliver as the first phase of this WG... any other ideas? any preferences ? any potential dates we can shoot for? 

- The current spreadsheet and original doc of all use cases  in the last bullet above?  That would be easy, as I think well be able to hash those out in a few days.

- A more formal , text / markdown style proposal or repo.

- A CRD

- 2 CRDS (dans plan outlined a v1 and v2 breaking approach)

- A set of scenarios that demonstrate various security models we'd like to support ( a few folks from the community want to get involved with this)

- A presentation to the broader sig ?

- A demo or prototype of how a new API might look (might be fun but.. might be a lot of work - but id be down to collaborate on something like this if someone was passionate about it) ?

 

Thanks ! Open to any ideas here for sure.

[jay vyas]

(oh oops, I meant subproject) :)... but, the same logic I think applies.

[Rich Renner]

This looks cool 👍 will take some time to process but I look forward to reading it through!

What coordination, if any, with the svc apis v2 goal for Septemberish iirc does this api v2 set have? I guess it's silly q, but my initial questions to myself were more about how the new svc concepts apply or could be leveraged when skimming through.

Thanks for sending the great index of links very helpful for new folks!

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/e096f4a0-8636-4612-8a48-23a56bd299f1n%40googlegroups.com.

[jay vyas]

Yeah, that's an interesting q.... No coordination to speak of, but a lot of user stories (~ 14/29) were around higher level integrations and things that can be built on top of the existing network policy API.... which underscores (to me) the core question of --- do we *need* to deliver anything, or is it sufficient to have collected user stories ?

One other thing I've heard which I think makes a lot of sense is that, from a broader SIG perspective, the timing isn't ideal to stomach API Changes that aren't super-critical ~ 

- there's just *alot* going on right now, in sig-network.  and it requires a lot of work to review the things that are going in, keeping the tests working, etc (there's a lot with ipv6 and dual stack and so on that I keep seeing pop up in prow), and of course the new APIs that need to be reviewed, etc.

- noncritical API Changes are going to be difficult to hammer out without a very broad coalition.... 

- That coalition, to be effective, would maybe needs to be driven by CNI providers.  Right now, our subproject is culturally more of a think tank, than anything else,  which is cool, but we're limited in our ability to really push things to the next level, I think.

The good news is, going back to that 14/29 user stories statistic --- much of what people actually asked for can be done by building things on top of Kubernetes!    To me, having seen the project grow over the years, this is really cool - it tells us that K8s really has turned into a framework that can be used to build, almost anything.

- opa integrations (add a level of indirection - mike's famous user story)

-  for namespace-by-name isolation , things like the https://github.com/bells17/common-network-policy-operator - almost hunaimously agreed upon but controversial from a theoretical k8s perspective.

-  possibly for some types of administrative defaults leveraging the open source bits (wherever they are) of https://github.com/openshift/cluster-network-operator.  Again, these are easy to build but hard to dictate as a global API, without being opinionated in possibly fragile ways.

- for converging ClusterNetworkPolicy APIs,  (calico, antra, and so on support this), seems like we could just reverse engineer an adapter that allowed you to deal with those CNIs bespoke APIs 

- Possibly other L7'y stuff doable via https://kubernetes-sigs.github.io/service-apis/, i.e. gateways and so on, which also seemed to get a lot of discussion.

So... to indirectly answer your question I think a very interesting service level networkpolicy-ish integration could be quickly be envisioned alongside the new gateway and service APIs stuff , and also alongside other things as well in the list above..... just not one that changes the core NetworkPolicy API... and that's totally OK.

.... and of course,  if we were to hack around on such a thing, and it turns out to be successful, then it might be something we can funnel back into the K8s community over time as a CRD or add-on or, maybe even, a template for some kind of things that might be interesting for a V2  NetworkPolicy API.

[Ricardo Katz]

IMO and after seeing (far away, just watching) what has been done in the Service API Sub project (Bowei, I can use your opinion here!), the next step would be: "ok, have we gotten a consensus of the user stories? So let's quickly present this and check if someone is missing something".

Then the next step is to organize all these user stories in a document that specifies 'how the new network policy proposal would work', 'what can be done' and 'what are the personas, the objects and their relations'.

I really like to use the "service api" example because for me the idea and concept is very well organized and explains exactly what's its proposal (specially here -> https://kubernetes-sigs.github.io/service-apis/concepts/) so after having enough categorized user stories, maybe we should:

1) Split what can be already achieved with small changes into NetPol v1 and propose them in a (or some) KEP(s) and implement, so users won't have to wait until the newer version of netpol to ship to have some functionality. Those are the Section 1 of Dan's document and can happen parallel to NetPol v2 discussions.

2) Jump into documenting the introduction and the concepts that we expect to exist in the newer Network Policy v2, the same way was done by the Service API Subproject. This might help to clarify what we want to achieve, will remove us from the 'zone of theoretical discussion' to the 'ok, thinking this way we can already achieve this or that, but will miss this or that case, let's try'.

About also moving with discussions, I think (and this is my and only my opinion) we're getting pretty counterproductive sometimes getting into the same point we started or coming back to discussions of 'how personally important is this to me', and those discussions get lost in the time. So, I think also that after we move off to 'those are the user cases we have' we should properly document them into some github repo (kubernetes-sigs, someones repo, whatever, but we need to have those discussions documented), categorized (using Dan's categorization as labels) so we might have upvotes, comments as history, etc and then select some of those issues to discuss into next meetings. GH for me still is the easier way to keep track of things :)

And although I'm not a huge fan of using Slack for everything, maybe having some discussions in a parallel channel (not #sig-network) about some user stories, or questions about why something should be this or that way would be faster than waiting for weekly meetings (or using mailing list, which tend to get dragged by the black hole of the current day and rotten to a next page, and then nevermore found unless someone asks your opinion about that 3 week old email) :)

My 20 cents ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/8e62cf0f-c733-4709-b7ef-cb9ef6940de5n%40googlegroups.com.

[jay vyas]

Thanks Ricardo,  good point, ok , yeah so your email  summarizes the other 2 basics points of view then ... (2) v1 (issuing and KEPs) and (3) v1-vs-v2 (strategizing) parts and story modeling.  

That naturally breaks down into 3 orthogonal sub-sub-projects .

(1)- hacking /r&d on a conceptual v2 type (ala dns-netpol-operator/default policy operators/cluster-policy) CRD .  

(2)-  v1/v2 overall strategy and k8s security modeling , which involves alot of what I might call 'water carrying' around user stories and docs.  

(3)- issues/keps for tactical v1 priorities that are orthogonal to the above .    these of course could be done by individuals in the community maybe or whatever

• Port ranges with exceptions

• Matching a namespace by name

• ClusterSelector for Network Policy Rules

• Add a level of indirection

• Named CIDR Blocks / IPSets With Synthesized LabelsSpecify network policy to a service

I guess for whoever comes Monday, we can start off the meeting with this new model , we can  let folks decide how to self-organize into different groups based on interests ... and then depending on how many folks get involved with specific projects or efforts, we can re-cast our meetings (if we need to continue having them) into more status-update/demo/hangout/collaboration to share progress on these different fronts.

[Andrew Kim]

My 2 cents:

I'm not sure we should start any work on KEPs or API sketches until we've reached community consensus on the user stories and their relative priorities to one another.

I think we've made some great progress on the user stories, but I personally don't get the feeling that we've reached consensus. I think a lot of this is because:

* Some of the terminology we're using is not interpreted the same way by everyone, maybe we need to spend some time adding more context and words so we're all on the same page.

* We're currently gauging priority by who is the loudest during meetings. We have ~30 people show up every meeting, I'd love to hear what the other 25 people have to say :).

* Folks have not been given enough time to noodle on the ideas that have come up so far and form an opinion.

So IMHO, I think we should slow down a bit and make sure we have community consensus on the user stories and their priorities.

Cody introduced a scoring method for the user stories last meeting which I think would be worthwhile to do so we can better understand the priority of each user story before figuring out next steps.

Thanks,

Andrew Sy Kim

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/29432f9a-31bd-46e2-8d1f-1205506e3c74n%40googlegroups.com.

[Jay Vyas]

Thanks Andrew  good points for sure. My approach would be a little different (not better , just different, and admittedly maybe worse).  Who do you think would be the best person to moderate that next step of consensus (maybe someone with a fresh perspective , like you :)? Or possibly someone that represents the CNI community directly?    Welcome to volunteers.  

On Aug 15, 2020, at 12:46 PM, Andrew Kim <kim.an...@gmail.com> wrote:



[Andrew Kim]

I think Cody had some ideas on how to get community input so we can start prioritizing the user stories, thoughts on running with that for Monday’s meeting?

Thanks,

Andrew Sy Kim

[Jay Vyas]

Yeah that is a good idea , if not we can see other volunteers that might be interested 

On Aug 15, 2020, at 5:00 PM, Andrew Kim <kim.an...@gmail.com> wrote:



[jay vyas]

Hi folks, 

Just to complete the circle here, thanks for all the feedback on this.  Since its been about a week, i think we can finally complete the circle on this thread.

- we're going to go back to a some kind of hybrid artifact to present to the SIG, (1) KEPs for smaller issues (2) a broader proposal doc (3) a potential CRD that demonstrates a POC of what we think would be a useful iteration....  This is so that folks can begin *doing something* even if that effort might be somewhat unclear in terms of how its ultimate manifestation unfolds.

- pardon the dust but we'll be putting stuff into  https://github.com/jayunit100/network-policy-subproject (or a company/organization fork if someone wants to propose one) , where we can start iterating on things in a little  more formally...  

- The starting  group will be about about 5 to 7  people from yesterdays call, across a few different companies (vmware, microsoft, ibm, google, serpro,...)

- Not 100% sure how this will pan out, but it wil be a fun ride for sure :)...   Either way, everyone's feedback here was super valuable so thanks - ricardo, andrew, brenner, dan, chris, and others!