Kubernetes SIG Network, 6 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WG-Network Policy API Bi-Weekly Meeting for 20220606

Description

WG-Network Policy API Bi-Weekly Meeting for 20220606

A

Okay, hello. Everyone today is june 6 2022.. This is a meeting of the sig network policy, api subgroup to sig network. uh This is a cncf certified meeting, so please be nice to each other and let's have a good day um as I was stating before I started, recording not too much on the agenda today. I do see a new face. uh Hi brian, uh would you like to just give us a quick intro while you're here?

A

What you're interested in.

B

Yeah um I recently took on a new roles principal at thoughtworks. They have a pretty heavy open source program and I've been a user of kubernetes forever. So just trying to find groups where I can jump in and help and see where I can get involved network is one of the ones. I work with a lot so.

A

Awesome well we're happy to have you. uh We definitely need help. As you can see, we're a pretty small community. I think we've been getting smaller, um so we're trying to uh increase our sphere of influence, moving forward um yeah and our agendas in the calendar invite, if you look back and and one of our main efforts right now is admin network policy which we're we've got to kept submitted and we're finalizing the state, the final stages of ap, the api itself.

A

So that's been our major piece of work and out of that, will come a lot more work. So, if you're ever interested reach out in our slack channel, I have a bunch of items that are going to come up that we need help with okay.

B

I'll throw a leave in there now thanks.

A

Yeah, thank you for coming um cool. So on the admin network policy, api dan. I got to your changes about a week ago. I think- um and uh I besides, that I don't think there's anything left to do. um Do you think we're nearing kind of merging of the pre-v1 alpha one version of this api, or is there much left to do.

C

Well, I don't think this is even pretty be one alpha one I mean this is v1 alpha one right, um I so yeah. I should have gotten back to this sooner, but I actually just tagged it lgtm hold uh now, uh so it now has lgtm, but it also has hold, because I was saying it would be good to get tim to look at it again, especially with the change that he made with ports to have the pointer to array.

C

He may remember in more detail what the pros and cons of that are, but yeah other than that. I think it is ready to merge and if he doesn't get a chance to look at it soon, then maybe we merge it anyway and you know there's going to be an alpha 2 anyway,.

A

Right, that's what I'm thinking I mean people are going to find bugs as we start implementing it. uh So I'm I I would like tim to see it too and I'll try to do a little more research. I said on the review on your review that I would do it and I haven't gotten a chance to. um I think if we can find an example somewhere else in the api or crd somewhere, where they're doing that. That would be sufficient right dan for at least the pointer to the array.

A

C

Yeah, I guess I mean it doesn't necessarily answer the question of whether it's considered a good practice right, fair.

D

C

We know it's possible.

A

Yeah yeah, we should define it. We should be able to define it as a good practice or not before we implement it fair enough um awesome. Well, thanks for all your work on that, um I will reach out to tim and just give him a poke to give it a last review and see if he has any huge problems with it, if not we'll, go ahead and move right along. So that's exciting any other questions with admin or policy yang.

D

Another question, but I just realized I I promised to do a round overview for the uh uh a cap updates, uh but I forgot to do that so I'm adding this to my calendar and I'm I'll make sure I do that uh for uh for this week, and I I I just took a quick look.

D

It seems like it's just all you know api updates and those look good to me, but I, as I said last time, I will you know, go through the cap one more time and see if there's any narratives in the description that has, you know changed since you know the campus merge and the new api has spawned. So I I I feel like there is something that might need to be updated in those lines, um but I'll I'll guess I'll.

D

Just push a commit on top of your uh your commit, so that we include these things.

A

Yeah feel free to steal my commit in your npr. If you want- and I can close it, um there is some unresolved and the unresolved items you'll see in the cap. Those are all should all be fixed, so you can also update that, but it's pretty clear yeah. I would do cool awesome. So that's exciting. I will definitely ping tim.

A

um You know next steps, in my mind at least, are possibly further explore exploration of dan's idea of an evpf implementation for this upstream. Just to like get people excited, spread awareness but more sorry, go ahead. Dan.

C

um So I realized it, it doesn't actually work as well as I thought it does, because you need to intercept traffic in at least two and possibly three places um because it has to happen after service proxying, but before network policy, um and and so there there's like.

C

You can't do it on pod egress, because that's before service proxy- and you can't do it on pod ingress because that's after network policy, um so it has to happen in the middle of the the existing plug-ins processing, and so that makes it a little trickier to to figure out how to generically insert it in a way that would work with all network plug-ins.

A

Yeah, no, no for sure I mean I think, reaching and trying to get it to work with all network. Plugins is definitely far. um I was thinking even before that just getting a poc, maybe that folks could just spin up locally and play with like and and maybe that's just with uh uh cubenet and upstream q proxy, like I think we could make that work to start.

A

um I don't know how much it's worth, because we can't do it with every cni, but.

C

I mean pretty much any ci that is not already using ebpf and is not using ovs you. You could probably make it work with a handful of iptables rules, so.

A

And you do you mean iptables rules pointing to bpf programs or just yeah yep and maybe a little off topic, but in some cases, if we're pointing a packet to a bpf program from an iptables rules, doesn't that you know not make it as worthwhile? Because technically you want to be hitting the bpf program in kernel space before you even touch ip tables.

C

I mean so for one. You know this is a proof of concept. You know not that, but but two I mean it, the the packet is still saying in kernel space right, it's not like yeah.

C

You know so fair enough, you're you're, not bypassing every possible bit of kernel network processing that you could be bypassing, but I I I don't think you really want like like a lot of times, people when they start to look at evps sure if they're like oh, we could just like directly slice these two sockets together and completely bypass everything in the universe and yeah you can. But it's gonna make it really hard to debug yeah.

D

C

I think, for at least like baseline implementations, we should be aiming for things that still mostly work like you know ip tables and things like that, but just using newer technologies, rather than things that that completely just you know, teleport your packets, you know through random places and.

A

Yeah but then the question is: why use evpn? If, if the performance isn't there.

C

Because well, no I mean it would well, okay, so for one like people, mostly aren't hurt by performance of the actual packet routing parts of ip tables. You know they're.

D

C

The the api of getting stuff into and out of it and the fact that looking up iptables rules, you know is is can be slow if you have too many of them.

C

So but, like you know, if you can turn 10 000 iptables rules into a single uh evpf call, then you win.

A

Totally totally sorry.

C

I totally cut out during that.

A

No, no, I we got you.

C

A

Yeah and I'm getting into the weeds, I'm more just thinking about uvpf but um cool. So it's a good idea, there's some interest. It may not be as useful as you first thought. um I still think it would be an exciting study for someone looking to get into ebpf.

D

A

To advise on so I'll reach out to folks and if there's any folks here that want to you know, think about it. Let me know I'm happy to help.

D

Cool I'm no expert in the ebpf at all, but uh I'll I'll, just I'll just say that for obs out of implementations you can definitely count on entry implementing it. It will be sort of like a reference uh implementation and we'll already start working on it. So.

A

Oh nice yeah we'll. Definitely I assume no, we will definitely do it in oven, kubernetes. I don't know, I will definitely be helping a little bit. I don't know if dan will, um but we got to get the api merge first and then we'll decide. I guess we could start a little early, but we haven't yet cool um the next action item. So as the api kind of kind of comes into into its own there's a lot of other stuff. We need to do um when you start thinking about documentation.

A

We need to start thinking about tools. We want to um start putting together for the annual network policy api. um Basically, the question is like what we want to do. Moving forward with the network policy, api repo like right now, it's pretty ugly and bare bones it's about to have an api in it. What else do we want to do?

A

um I'm looking for you know other ideas here with the goal in mind to make it kind of a place for folks who want to learn more about policy kubernetes policy in general, so maybe that's the coalescing of network policy docs and then also the addition of new admin network policy tools, something along those lines, but need help with that. um There's a lot to do there, so we just need to make it better looking because it reflects our our working group and right now. It's bare bones.

A

So, just something to think about: I'm not really looking for folks to raise their hands yet because there's not action items, but there will be.

D

So so, in terms of documentation, um I was thinking on lines of what. uh What exactly in your mind, will will be something to be added in addition to what the cap has right, because so so the cap is sort of like the proposal right. So it does have all the api documentations and how we arrived at that. But I guess in the in actual repo, the documentation might need to be more focused in terms of use cases and how you know people can get started on using those things. Yeah.

A

Yeah, I mean no matter how good of an api we have if we don't have good documentation and a good. You know this is how you get started framework. It's never going to get used so yeah.

D

I know I know but, but I feel like the cap has a already has a good section of five or six user stories with sample apis that we can just as a starter, throw in there because right now it has something like if you wanted to isolate every namespace in the cluster right. What is a I mean our policy that can enable that- and this is probably the some first bits we want to throw in the documentation for it.

A

Right, I agree so first bits we can pull from kep. You know as kind of a colorful exploration as where we can go. I I definitely. I would one day like to look like the gateway api docs because they're, in my opinion, pretty good um and they have like a dedicated website already built and it I think it's pretty easy to build a website like that using mktop mk docs, which is the tool they used. So I'd like to look into that for sure.

A

um So we have a website rather than just a repo, um that's definitely a first goal um and beyond the kep. You know I think it'd be nice to illustrate what yamls are going to look like for a couple more common use cases so so start with the kept right yang and then expand on uh providing some more sample yamls just for folks who maybe want to go a bit deeper.

D

Yeah that makes sense.

A

Cool um and then the last bit I had on there is adding cyclonus. So this is less about adding cyclonus to that repo more about do. We want to store like more tools, network policy and policy related tools in the network policy, api repo, as well as like admin, network policy, definitions and stuff like that, or should we look at making a new repo because, obviously we're going to need to add some developer tools for amp, so those are going to have to either live here or somewhere else.

A

Well, I'm thinking they can live here. That's my first inclination because we already have a repo. It makes no sense to spin another one up unless we have to so yeah. I agree for now.

D

Just just as a reminder: what tools will we actually thinking about foreign policy when we were talking about it? I know you know we wanted something sort of like which illustrates how maybe deny allows in the by the time the baseline, allow you know, work together, so so, in today's context, maybe something really similar to psychonus in in the sense of if we have both these three or four policies stacked together and some of them can even be baseline um and then what will traffic look like from one part to the other?

D

Is that some is that the uh the tools that we're we're having in mind or right now.

A

I agree: that's like the first step I mean cyclonus is more of a conformance engine, so I was thinking we just add support for admin, our policy there, but then also having some sort of cli to help developers better understand the security posture of their cluster with a simple command right.

A

So, like maybe a cube cuddle plug-in that says, like cube couple uh cube, could will describe a pod and right now you can do that for network policy and stuff, but maybe you could do like describe security context of a workload and it shows you like the network policies, the admin network, policies, etc. That are touching that work, that workload and if traffic maybe is going to be denied or allowed. I don't know something along those lines.

D

We do we have that for for um for upstream kubernetes, regardless of cnn. I I I find that hard to believe.

A

Right now we just have disc, like you can describe a network policy, and it just puts it in. Like so cube, cuddle describe network policy a and right.

D

But it doesn't really show you what.

A

What to pause or selected whatever right? It makes sense. So I'm thinking we have tooling that extends that quite a bit right so like basically make it easier for an admin to understand the total security posture for a workload right, and we had a section on that in the cab.

C

So and if you're going to be implementing admin network policy in evpf you're going to have to write some code, that will look at the current sets of namespace and pod labels and policies and figure out, like all that stuff. So you can translate it into the data structure that the ebp program will use so like. If you're careful, you ought to be able to reuse that same code in the you know, figuring out which pods this network policy applies to for debugging purposes, code.

D

C

Same thing, right.

D

Right and- and I I think it's also the case for our cni's, because for whatever cnn was implementing this, I would. I would believe that the same thing will happen right, so in cni they must have some sort of like internal stores on you know what what parts are this policies selecting and what are the ingress and egress peer currently, so um so, if we just pull that out from a cni cache or or whatnot, it's also, it's gone also gonna work.

D

You know really um smoothly, but uh I don't want this to be tied to a specific scene, either right.

A

So I had some thoughts this morning kind of along those lines like we could almost mimic what kpng did for network policy like decoupling, the kubernetes bits um and providing like a clean api, so that you know folks who are implementing only have to implement responses to an api, um but there's a shim layer in there allowing you to do observability, troubleshooting everything, but obviously that's a little further out. Just just a thought I had could be cool. You.

B

Might ask a maybe dumb question, so is you guys are providing the api for admin policy and then each cni will then implement it or okay.

A

Just like network policy today, um some cni's don't even implement network policy, um but some do so so we'll be following the same thing: we're just finding api uh inventors will do what they will same with the gateway api, et cetera, et cetera, but gotcha. Lately, there's been some more initiatives towards you know, looking at bringing some of this functionality upstream or closer to upstream, maybe in the sig groups. So having like, we talked about before reference implementation upstream.

A

That folks can just pull and plug really quick. Now that we will make no guarantees that I'll work with your cni's but it'll be yeah.

B

A

Then you don't have.

B

A bunch of people implementing it like completely differently for ebpf between cna.

A

Right and generally there's an extreme lack of knowledge around kubernetes plus evpf I mean psyllium, has everything and there's no cilium folks here so here we are.

B

The user of celium, but definitely I don't know how good I am at extending it.

A

So um it'd be cool to bring some of that that knowledge to the wire community for sure, okay, um I think we have some good things to go on. I have an action item to poke tim, which I've gotten pretty good at I've poked him a lot throughout this process.

A

I don't know if he's annoyed with me yet, but we'll see.

A

Otherwise, there is also going to be an article ying and I had started a while back that we're going to try to put out onto their waves once this is kind of finalized and merged, just kind of presenting admin network policy, and we also submitted a kubecon talk last week for north america uh to kind of present a p to the community and see where we can go with it.

A

So yeah there's a bunch of places to get involved brian, if you're really excited to reach out in slack and happy to plug you in anywhere I'll, be at.

B

Cubecon as well cool.

A

Cool yeah we're hoping to be there. Okay, anything else come.

A

I'm folks take that as a no well thanks, you all for all coming today, thanks for the continued review. um Oh sorry, we have one more edition: hey victor how's, it going.

A

We were just wrapping up.

D

uh I think I think uh he or she just uh was just connecting to audio and didn't hear. Oh, I gotcha I gotcha hi victor um we're just measuring the. We have a new edition here. So uh maybe you want to introduce a little bit about yourself and uh uh what brings you here maybe.

A

Oh yeah, I'm actually just uh interested to learn at this point cool. Well, we were just wrapping up the meeting for today, um but if you want to learn a little more about what we're doing and definitely check out the agenda, uh we have most of our action items. We've been doing a lot of them around a new resource called admin network policy, but you know that's coming to an end and we're looking to expand and wrap up uh moving forward onto new things. So, okay, we also are all on uh kubernetes slack.

A

So we have a channel specifically for this working group so feel free to reach out with any questions along the way and uh yeah we're happy to have you here.

A

Cool okay, pretty short for today. uh Thanks again, I hope you all have a good rest of the week and we'll talk to you soon. Bye.

D

Right thanks, bye.