Kubernetes SIG Network, 31 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Bi-Weekly Meeting for 20220131

Description

Network Policy API Bi-Weekly Meeting for 20220131

A

This meeting is.

B

Being recorded.

A

Okay, hello: everyone today is monday january 31st 2022.. This is the sig network policy, api subgroup to sig network. This is a cncf certified meeting, so please be nice to each other and um yeah. Let's have a productive meeting today. So welcome back everyone, it's actually the first time we've met since the new year, even though we're a month into it hope everyone's year is going well so far we can go ahead and roll right into it.

A

I see the fqdn policy folks are going to propose some of their thoughts to sign network uh in the upcoming meeting. Do you want to go in a little more to that.

C

Yeah, absolutely um so we I think last year, near the end, we discussed the fqdn selector a little bit in this meeting and basically, what I'd like to do is this coming sick network meeting just take that idea as it currently stands to sig network get a broad up down on whether we're okay, putting fqdn support into uh upstream kubernetes. I think that's like the bare minimum support that I think we need from sig network to get together a cap and really hash out the details of this. um You know if we can get more.

C

uh You know clarifications on, should we add it to the existing api? Should we make a new uh object? We can obviously you know dive into that, but just having a up down on yes, people are okay with us. Adding ftdn support would be a good starting point. We can start iterating on the cap and take things from there so yeah.

C

To that end, I guess I wanted to run through the proposal once more with the group um just point out a few things that I've added or changed since we last talked about it, get any pieces of feedback things. I should be sure to mention uh when we talk to sig network, um you know just general open to comments situation.

A

uh Cool yeah, I think, that'd, be awesome. I gave you the the ability to share just now um awesome and as we go I definitely I think I have a little more insight now after been grinding on the amp for the past couple weeks as to what's going to be possible, but at the end of the day I do think it's really smart to go ahead and take it to sig network earlier rather than later. At this point so.

D

Hey so real quick question um is this thing added to the agenda for this thursday.

D

I don't know if you're responding, you might be on you.

A

It it is on the agenda.

A

C

A

Oh wait. Sorry, no.

C

It's not it's not on the uh sig network agenda. I need to add that there yeah. Let's do that, can you see my screen or did that? Go.

D

Away, no, I cannot see it.

C

Okay, let me try this again.

A

There you go, but somehow you're losing your audio. When you share your screen, I think.

C

Yeah, it's really there you go okay. Can you hear me now yeah? I got you hopefully see what I'm doing all right, perfect um yeah. So this is the um doc that we've been just sort of going back and forth on uh the first up. Is you you andrew you made a valid call for user stories, so I sketched out a couple here: um they're fairly basic, but I think they're a decent starting point.

C

We can see if people have any other ideas at this point, I'm targeting a persona that is sort of an application developer or a namespace owner, so very analogous to uh the network policy uh owners that you know we kind of currently have today.

C

This would be a namespace uh concept for the time being, and the idea is you want to specify some egress endpoints for your workload, but you don't want to manage a list of ip blocks, it's easier to read and understand ftdn policies, so that's sort of one basic use case that we're targeting uh another one is sort of a variant of this I've. I've heard a couple: customers complain, especially about ipv6, addresses being a little bit chunky and unwieldy and then preferring to have fqdns instead of that.

C

So that's just a really a sub plot of the first user story, which is you know fleshing that out um story. Three is an interesting one and I I anticipate a decent amount of conversation here this this feeds into the idea of sort of wild card specifiers.

C

um This is this is something that I have run into in terms of customer use cases. But it's not. You know we can talk through what we want to do about this in open source, the idea being that there's a whole suite of apis or endpoints that you want to allow whether it's you know your on-prem network, it's your cloud providers set of apis. um Those are just a couple of examples, but the idea being that you want to say star.mycloudprovider.io or star.myonprevnetwork.com, or something like that.

C

You want to be able to allow list a huge chunk of fudns without having to explicitly lay them out one by one. So this is another use case. uh In this case, it would have to uh be with a wild card specifier.

C

um So these these are some user stories that I've added right now, um obviously an open call to anyone. If you don't have access to edit this doc. Let me know please go ahead and add more as you think of them as they come up, but any questions or concerns about these right off the bat.

A

I first of all I think, story. Three has a lot of merit. I've seen that before as well. um So that's really great story. Two, I don't know if it warrants being its own user story, because, like fqdn, should be fully talking about layers above ipv6 right so like like for this proposal, all that matte, like we don't care. What's behind the um fqdn name, right like it seems like it's a layer lower.

C

Yeah, that's a fair point. I can. um I can just call out that we would like to support ipv4 and ipv6 as a part of this um yeah. No special treatment, ideally for either um address.

A

Style totally totally that's that's kind of what I was thinking um like at the end of the day. I mean it's not true layer, seven, because any implementation would just be translating to ips. So I don't think it really matters. You could have a story that says like as an application developer. I I want to um avoid typing in complex addresses or something or something on those lines, but right.

A

Cool yeah, I think these destroyers are good, so far I'll think on it on. If I can of any others, I can't off top of my head. I like that it's a narrow scope um that should help insignet, um I will say I can really easily see this being rolled into an egress firewall object rather than just this really scope. Really narrowed scope um use a set of user stories, but we can talk a little bit more about that as we continue.

C

Yeah, that's fair um yeah, so that's that's sort of a good segue into the api proposals, um and this is where um you know we can present these to sig network, but I doubt we'll get a any sort of you know resounding consensus here. There's there's a lot to dig into, um but, broadly speaking, um these haven't changed since we last talked about them as a recap for those who weren't there, there's two ideas: we're kicking around right now, one is to enhance the existing network policy. Spec uh like the v.

C

uh We would, you know, probably add like a v1 alpha one or something to that effect, and we want to add fqdns as a subfield into that. um The thinking behind this being that it's the one stop shop for uh writing boundaries around your workloads. Today, it's easier for users to understand and discover and use properly, if it's all in one object rather than having to compose policies across various different objects.

C

To that end, I think there's a little bit of discussion around exactly where we would add this in the policy spec, um I'm currently proposing a new sort of top-level field in the spec itself called that egress fqdns and we use the policy types array here as a mechanism for feeling closed and allowing older cni's to just you know, restrict traffic uh carte blanche without having to really dig into the details of the egress fqdn policy, and so this is something that I've detailed a little bit here and, under this section, failing closed on how old, cnns would still parse these policies safely.

C

uh The alternative oh, go ahead: yeah.

E

Yeah, I think yeah yeah, the doc is not focusing on the api. Are you still.

C

uh Okay, here we go. I think I was pausing sharing. Instead of pausing the audio share, it's a little bit tricky all right, um yeah. So sorry, the the api uh that I'm describing is here of adding a top level. Egress fqdn, um the you know.

C

We have a section on failing closed, uh which sort of explains how we would uh handle this in older cni's and then there's a couple of options in terms of alternatives, of extending the existing spec either adding it to the network uh policy pure struct, alongside ip block- and um you know, namespace electropod, selector there or adding it to the network policy address rule with the network policy, pier um the trouble that I'm having is that the semantics of an empty network policy don't seem to be uh fully called out in the api definition.

C

um It's it's just not explicitly defined, which at this at this point, means that cni's may choose to interpret it, how they will um so an older cni. You know they wouldn't see the new ftdn field, they'd just see an empty object and it's unclear how that would behave. They might just fail open. You know allowing all traffic which would not be ideal.

C

um It's a similar policy uh problem with the network policy egress rule uh struct, which is basically that we have a list of two um specifiers um an empty list or a missing list means allow all egress traffic, so it would basically fail open. So if we were to add a new struct there, um you know that that's definitely a non-starter. We would just be failing open for existing traffic. So that's that's the pitch for how we might enhance the existing network policy object. um Are there any questions or discussions?

C

Or you know things to clarify here.

A

I like it, I I think it's really smart, adding the extra list it's a little bit verbose right, but in terms of adding another feature to network policy, you're going to have to be especially for upstream to even consider it right.

A

But I I at first glance I think. Well, I guess I've looked at this before I. I do like it.

A

um I think, on thursday, in your presentation, like really just zero in on explaining to people how it fails clothes, because that that's something that's hard for a lot of folks to understand, and it will be like the number one question right.

A

So I think you've done a good, really good job of describing it here, but um maybe even just throw together like a slide or two and um explain it that way, and then I mean, if you can get a few people on board, it would definitely be the easiest way to get this work merged. It's just adding it to network.

C

Policy so right that makes sense yeah I can I'll I'll probably have a slider too. Very specifically to this that's a good call out.

A

And we can now supposedly we can bring back like v1, we can bring bring back v1 alpha. We could like make a view on alpha 2 for networking.

C

A

So that that kind of helps there as well.

C

C

Awesome yeah any other um thoughts or concerns um piece of feedback.

C

All right uh yeah, so this is proposal. One enhance the existing network policy object um proposal two um is to add a new resource, uh something like an fqdn policy, um which you know we would take.

C

You know from that v, one alpha one all the way through, but it would be a separate policy object that it looks very similar to uh network policy. You know you've got a pod selector um describing which workloads you're described targeting in this case. It just has an egress uh specifier, because we're not interested in ingress at this point in time uh and then the the guts of the specification are still. You know the same thing as uh what we're asking for in the first proposal.

C

You, you have a list of matches list of ports and you sort of build out the cross product pretty similar to how network policy works. Today, um yeah I mean this. This one is it's tricky because now you're adding another place that users need to configure stuff and then, if they ever want to debug hey, why is this traffic being allowed or being rejected? You have to check two places.

C

It's a little bit more fraught a little bit more error prone.

C

That's that's! This uh thought around this new policy object. Anything folks want to call out here um this. This is, I guess, where the the can of forms opens around just having an entire egress firewall uh resource or stuff, like that. This is where we can really scope creep on this.

A

Yeah there's two problems too right. So if you scroll, I was you know, I had read dan winship's firewall kept and he makes a good point like like really with fqdn. A whitelist model is the way to go right, um so that is another rationale for it to fit nicely into network policy um and not to fit into an egress firewall sort of policy, because that would more likely be geared towards the admin. I would imagine right and in this proposal, you're you're more focused on the developer right.

C

A

um That might be another push towards one, um the you know, I guess.

A

I don't know really at this point I've after working with them for a while anything's possible. It's just like who? Can you get the most people to raise their hands and say we're gonna help push us through.

A

The problem I foresee is, you might get a lot of yells for network policy v2, um because what we've heard at least what I've heard yang might be able to correlate this in the past. Like couple weeks of really intensely working on admin, network policy is like. We are kind of done with network policy like we don't want to open any more cancer awareness with network policy. It is already too complicated. Let's leave it where it is and move forward. um Do you kind of agree? That's the sediment. We've gotten yang.

F

F

A

So what do you do raul if they're like if they come back with? uh Okay, this needs to be built in a network policy v2 I mean.

C

Yeah I do, I don't really know what the uh game plan there bears. I mean I I by my understanding network policy. V2 conversations are non-existent at this point like they're, wherever we left them some odd months back.

A

They were run by a few folks from jupiter and the last time I looked, I think, jupiter closed their some part of their open source community. So I haven't heard for a long time about that, so yeah pretty much dead, yeah.

D

I mean you bring up a very important question right, so whether we want to put it in the network policy or not, we went back and forth and I think, as you, I think that everyone is pointing out, there's not enough appetite to like continue to extend network policy.

D

I think the time has come for us to like come up the network policy detail, but in this the time it takes for us to network from network policy to we agree on what the scope is by the time it comes out. What do we do in the meantime? So I think what we're suggesting is, like you know, instead of I think, there's so much pushback on trying to achieve the network policy. He said, let's do through fqdn, and you know if so that way,.

D

They can they can easily make it work with network policies, so that was the main that was intact right now,.

F

D

Ourselves, a situation where, like you know, we can't make progress on either front because, like everything is like stalled, uh because it's it's I'm network quality, I think we've been talking about it for like a year at least right, so yeah.

A

No one's picked it up. I mean I, I would love to and that's kind of my next object, but yeah yang and I have been pretty full to the gills on cluster scope policy for a long time now now.

F

There is a third.

A

Avenue um so we have, we still have that repo. We haven't used it all so well, a few things here. Admin network policy is firstly going to be implemented as a crd.

A

Technically we could go ahead and agree on an api and prototype that and have it upstream, as a crd in our sig network policy, api repo as part of the policy uh api group, because it's it's an api group but owned by us. It's not officially in tree. I don't believe, um and we could do some stuff up there.

A

That might be a way for us to get kind of fast and dirty um on getting something that people can use and then, as we move down the road, we could look at actually like getting a cup formally approved. Now I need to talk to tim and sign network and make sure that that's not like yeah.

D

A

D

Let's put that thing as a proposal and see what happens uh so so if I hear you right andrew what you're saying is um not pursue fqdn, I mean you're, the the one of the proposals that you're suggesting not pursue the pdm crd, but like make it part of the admin network policy.

A

No, no, not necessarily admin network policy yet like so. If we were going to pursue a new crd, we would we would um have to make a new object for fqda. Just as a start. um To be honest, in my opinion, I would love to toss this into network policy, and I will help push for that, but I just have a very strong feeling. After conversations we've had with tim, especially like in the past two weeks that he's going to shut it down.

A

I don't know if you all have had conversations about that, but I mean.

D

He's been commenting on the doc, but we haven't yeah. Did he comment anything at all on the.

A

He did comment on it.

D

C

He I had a conversation with him that was in a similar vein about you know. Where does the community draw the line on you know? We don't want to take this entry, um he he didn't have any strong. um You know decisive guidelines at that point in time. He, the indication I got from him, was that fqdn was right on the border of we've been talking about it for a while. It's not in some sense a massive change to the behavior.

C

um It's it can be thought of as an incremental improvement, depending on your perspective, so I think he I think his stance was he's. Okay with it he'd like to hear if anyone else in the community has um strong opinions against it, but that that was a few months back, so he may have changed his opinion. Since then,.

A

I you know: we've really outlined that I'm starting to think about it more like we've. Really we have. We had some folks pushing for v2 they kind of dropped out. Now we have this desire for the new feature fpdn.

A

We also have a pretty concrete list of qualms with network policy v1 we we know what it does well, we know what it doesn't do. Well, you know if they come back with well. This should be network policy v2.

A

Why don't we start building a network policy v2 with a narrow scope? You know more focused on fqdn and, if folks, like start coming out of the community and actually calling for features, maybe those features won't be in alpha, but we can build them into beta. The key will be as long as we build the base api to be extensible right.

A

That was the problem with network policy like it was not built to fail closed and we're seeing with at least admin or policy we're almost there, and I think I can speak for yang and I like, we feel like it's built to be extensible like we feel like we could easily.

A

If we were focusing on our south traffic, add fqdn as a selector as a peer, I mean it wouldn't be rocket. Science.

D

By using a status status field, not even.

A

How do you know.

D

If, like, for example, a implementation does not implement the ftdn, then how would.

A

You put silencing, we basically have added a layer of indirection and and a strict enforcement that um within that layer of interdirection there's a list of selectors and only one selector can be set for a given um rule, and so if the implementation sees an empty selector set, it just does nothing doesn't allow it doesn't deny it fails, close right it. It interprets nothing from an from emptiness and that's kind of how the api is built.

A

um There's a little more notes on the amp cap as well. That is directly related to that. But what I'm saying is right now: if we go to them, they say no to adding network policy. Then let's build network policy v2, but let's make it super simple. For now, let's make it fix what we don't like about nerd policy, v1 and add fqdn selector.

A

And that's it unless people come in to help right or unless we have community involvement right.

F

A

Right because because then it's not a total reboot, it's not all this work on you guys to totally remake network policy. V2, it's more of let's reform network policy, v1 make it extensible, add fqdn, move forward.

D

So actually that was the original intention when uh we're talking about it. So so what we'll do they're gonna right now, based on the conversation that we have had so far with all the folks, our focus is trying to get the fpdn feature um out because we have pending customers who are looking for it. So, having said that, let's see what the network the sig network has to say and if they insist on doing network policy, then we'll we'll have to go back and make some adjustments on our side. But otherwise we will.

D

We will push, for I mean we'll, ask your opinion. Let's say like you know it is. The authors of this cap are leading towards fkd and being a separate crd and see, and if they come back and said no go back and then we will talk about it, saying that we did discuss and there was like you know um for some folks who are advocating that we should put it in the nether college and see what that.

A

Yeah and the only piece of advice, I'll say for that is get the meeting recording make sure you have it and take good notes so that you don't end up having the same conversation with signet work four times yeah. That was a common pitfall. We've had um yes cool yeah, um but I like I really like what you've put together here. I think it's good work, um I just I wish I could give solid answers, but I'm not the boss right. So no.

C

Absolutely um but no, these are.

F

Very valid uh good points, uh one quick question I have on the technical side. um I think I'm maybe sleeping a little bit when you were talking about the two proposals we had in terms of adding this into the network policy v1 api and one is adding this to appear and the other is adding to the egress rules right. So, oh, okay, cool, so the proposal, one. Okay, I think I'm talking about the proposal, one here, so how how was uh um negras fqdn's you know this proposal will not fading close.

F

Can you can you explain that again.

C

uh Yeah, so the idea behind how it's going to fail closed um is that we have the policy types field right now, right.

F

C

Which can be either ingress or egress right, so my my um what I'm saying is that, right now what we can do is.

C

We'll add a defaulting layer that basically, when the api server sees an egress fqdns field, it populates policy types with egress and so for old cni's. What they'll see is they'll see a policy type of egress and they'll see an empty list for the actual egress. uh I see so.

F

So so sorry, then they wrote, but so what? If? What? If we don't go that route? What if we say that? Okay, because this is a new feature um in our policy you can get away with you know just specifying a bunch of ingress rules and not saying the policy type being ingress, because that's something that's really implicit right so and cni should know how to interpret that implicitly, because you only provide an ingress frame, there's no egress rule. um But what? If we do something like okay, fqd and this new feature right.

F

So if you progra provide egress fqdn as a bunch of rules, we mandate that people specify in the policy type um which says this is a new type. Maybe something called egress fqdn right. So so, instead of ingress and egress, we explicitly provide a new type to the to the policy type and the c and oc. And I will look at this type and don't know what to do, because it's an egress fpdn and they don't know what to do with it.

F

So we especially separating egress and egress fqdn2 to essentially mean different things and there's no sort of like interwinding with each other, not even in the policy types. Would that make things a little bit easier.

C

Let's see interesting point, I'm I'm thinking about what that actually.

D

Would you would you mind adding that text to that yang because that's definitely a worth a proposal that maybe added proposal three, I guess or like a proposal. Okay,.

F

Yeah yeah I can. I can, I think.

E

uh I think, uh but I don't think it will make it any better. I mean the reason is, uh if you add a new policy type, they will not be able to see it anywhere right I mean because because they are old cnn, so they won't be able to make decisions based on the new policy type, because.

F

I that that's a point, uh that's a good point. I I wanted to. I wanted to say this because I I've been, you know working on entre as a cni and uh I can not. I can definitely not speak for the other cni's, but as far as who I remember uh and tria, you know there's some processing we do with network policies.

F

So the first thing we do is that if people in the spec actually provided explicitly a policy type, whether it's ingress, egress or ingress and egress, then we know immediately what to do with the policy, because people has explicitly provided this value right. So now we know that you know maybe ingress needed to be locked up only for the ingress rules, uh the the things allowed in new grassroots and for the egress. That's the same thing right, um but there are a lot of cases. I don't.

F

I think, when people actually write network policies, they have the tendency to actually just skip this policy type field. So now it comes to the cni implementation to actually impress interpret this for them right. So if people just provided the ingress rules and not actually specify the egress in the network policy spec now, the cni would know to just basically put the ingress tag onto this policy. So.

E

Yeah, I agree with that, uh but I think uh the policy I agree. I definitely agree with your argument that, like specifying the policy type will explicitly will uh will actually make the cni provider's life very easy. I I would feel that I mean for egress network policy, the policy type I mean we can just retain the existing policy type, which is egress. So if policy type is not specified, then the cni provider will not react to it.

C

Okay, so just quickly before we go down as far as I understand it, based on the documentation, the api server will default a value for policy types if it's not specified so before before any cni even gets a hold of this policy type. um The api server, because this is a built-in type, will inspect it and uh fill in appropriate values into that string. Anyhow, that that seems to be what's indicated in the um the api reference.

F

In that case, my memory would actually may be serving me wrong, so so that that's also a good indication that a cni when they receive the policy, they should inspect the policy type at the first thing as a first thing right before they even actually go into looking at the positive actors and whatnot. You know, logically speaking, when they got a policy, and you know the policy pops into the reconsider or the controller. What not they should.

F

The first thing to do is they they should look at the policy type so there, so the policy type is where we essentially inform the cni. Now the statistician and understand your point being um you know, because we, if we introduce egress fqdn as a new policy type, the cni might not even know what to do with that right. So so in cni's they may have a switch statement may be saying case ingress to do what what and case egress do blah blah blah. They might not have a default, for you know something policy type.

F

They don't understand that I I understand this might be a problem. um Yes, so I I guess this might just be a you know, a tricky thing that uh that we needed to um needed to take into consideration, because I know the policy type only came into being um because there was something in the similar lines when egress supports yeah supported egress yeah, when he was ruled.

G

Off network policy.

F

Were added um because they wanted to avoid exactly the situation like this? They have added the policy types, so my understanding would be you know it should be reasonable to let cnice know that they should be inspecting the policy types and only accept or only process policy types that they can understand and not. uh You know just go ahead and you know do some.

F

um I don't know if that's the same thing to say, but you know that my point being, if we add a new policy type, um they should there should be some mechanism for them to know that you know this is a. This is something that I don't understand. I cannot proceed with, but I don't know if that's a safe assumption to make um but anyways, but I think there will be definitely a lot safer than basically putting egress as a reused egress as a policy type for this, because that would definitely confuse cnn as ocnis.

F

um That's for sure,.

E

So janga, what do you mean by confusing the cni's, because I mean, if they're behind in the api I mean they won't, they won't see the spec at all, so they will treat us as if it's an empty network policy right I mean.

F

Yes, so so the here's, what I think, uh if let's say you put, uh you have fqdn rules and the policy type is egress. Now the cnn will look at the spec and says: okay, this is an egress policy. Now it goes into the um egress rules which found it empty right now. Cnn would interpret this, as user has supplied me a egress policy which has no egress rules in it, which means you lock everything down or allow anything or not right.

F

Basically, the default behavior, if there's no rule provided and that's not what we wanted. What we want is that a cni look at the policy type and realize hey. This is a egress tab that that I don't know, and then they they report, an error or you know, do do whatever they do like in the cnn processing and not just um you know,.

C

Yeah the benefit of interpreting it as an egress um is that an an egress type policy where no egress rules are specified is very explicitly defined as being denial, so that has the side effect of just shutting down all egress traffic right which which, which is which I would argue in this case, is good because at the very least we're not allowing any traffic that users don't want out.

C

um Maybe it might be inconvenient for users, because now they'll, you know, they'll be rejecting all traffic and they'll have to go dig into why this is happening, but since we don't have any established mechanisms for cni's to really report hey, I don't know what to do with this right. We don't have a status field. We have no way of really surfacing this to the user in any sort of meaningful sense. I I I personally believe in you know we can definitely debate this. I think there's valid arguments for both sides.

C

I think it makes sense to just shut everything down um and have users come in and realize that their cni doesn't know what to do with this, rather than you know letting us fall through potentially undefaulted switches.

F

I see I I see what you mean, yeah, that makes sense.

C

To me too, but I mean this is a great point. I think I'll I'll try to add a section here um and maybe tag you see if you can um make sure that whatever it makes sense and add any context, links sure.

F

But but I mean this is to be. To be honest, this is not like a. I don't see this as a proposal. You know I I don't think all of these uh are uh are a good way to to add this into the v1.

F

So the better way definitely is to uh you know, create something from scratch, uh so that we don't have to deal with the uh uh the the things that we didn't do right for the network cv1, but um I'm just trying to think uh if there's any chance that we might be, you know squeezing something to be one and not warriors about. You know adding a completely new different resource.

B

um I I just want to say that uh if we do try to add this as an egress policy type, uh what yang said uh I do want to second that, uh failing close on you know for for the for the egress default rule uh might sound okay, but I think, as from a user's perspective, it's a pain, and if I have services which were working fine and after applying a policy all of a sudden things stopped working. In that name space or in multiple name spaces, it is going to be a pain.

B

So so the user experience is probably not good, not going to be good and- and I think, even for the cni, it might be hard to figure that out like why things stopped working.

B

uh So I just want to second that, but if, if we can't find a way which does not degrade the user users uh experience, I think they'll be better.

E

E

uh Yeah so one point here, like I mean it depends on the cni provider implementation right. If they don't care about like the policy types, they would, even if I send egress nat uh in the policy type, they might still implement d49.

E

uh So I mean it really depends on the cna provider and how they're actually implementing offices.

C

Yeah, I just I I feel like the trade-off here is between it being a pain to users and it being potentially like a security problem. um The benefit of physic feeling closed is that someone will realize something's gone wrong immediately and be able to roll back and debug.

C

If you fail, silently, which is basically what's going to happen, if you add a new type, then sure all the traffic that was going on before will continue to go, but until you send out bad traffic and test that it gets denied, you won't realize anything's gone wrong, which I mean you know.

B

I I I agree from the security perspective and I think that should be. We should find a way which fails close, uh or rather, we should find a way which.

B

I don't know if there's a better way around this, but definitely I agree that, if secure, if it's between user experience social security, then we should give the security a higher precedence.

B

But if we can can we find a way which which uses both of those concerns.

A

Hey well, I I think I do think that's a little I I would bring it to cignet as the proposal stands honestly in my mind, I I think they will res they would respond better to an explicitly fail closed, um but for now we can always debate the api a little bit later and trust me. It will undergo many iterations, I'm sure, um but I I think you have your head totally right on your shoulders.

A

I like the way it's going and it's gonna force cignet to set a precedent for us and moving forward and regardless whether it's a longer longer way to us getting new features in or a shorter way. At least, we will be able to get new features in um we've, tripped away, some of that with admin network policy, and I think this will kind of close the book, especially for the developer persona. So I'm excited thanks for doing this work. um Let's hope it goes well on. On thursday, oh sound.

C

Yeah I'll um I'll put together a presentation and share it with folks if they want to provide comments um but yeah. Hopefully this goes well thursday.

A

Sweet yeah and just throw uh a note on the agenda I'll go ahead and do that so that you're, like at the top of the agenda.

F

A

um Cool okay, thanks! So much earl, that's awesome glad to see some more interest here um and in the last few minutes I just want to give a quick update on amp. um Basically, we are in the final stages of kepler review, pushing really hard to get the cap merged by thursday, which is the kept deadline.

A

um So if you want to check I'm not going to run through everything, that's changed because a lot has changed. um But if you would like to see what has changed in the api, the cap is pretty much up to date. um Yang. I did see that the pr reviewer just gave some comments as well um like 20 minutes ago. So that's good news for us. um Is there anything else we should hash out while we're on this call around admin network policy yeah the.

F

The poverty numbering issue right.

A

Oh, my goodness, gracious yeah so just to fill everyone in we've been arguing almost well, not not internally, actually yang aztec. I think we've all been in agreement, but whether or not one is the highest priority or the lowest priority, and now it seems to have wanted to be flip again. Flipped again.

F

A

F

I I left this. I left this out intentionally um on friday because I was trying to address every other comments that tim had on on there, um but you know this one.

F

um I I do get a sense that uh you know there are other people. I know casey included, didn't like the way that we put zero as a special case um for for the priorities, um but if we do actually flip things around, I think you know one being the highest precedence and and blah blah blah and we keep zero as the default will be really really weird, which doesn't really make sense anymore. So I guess we definitely needed to find a better.

F

If we do wanted to fit this, we definitely need to rethink about the baseline problem again, which I really don't know what to do. At this point,.

A

Yeah, I I don't know, I actually don't know if I agree with you on that, like it, if one was the highest precedence, the most important value, it's a little, a little more explicit now that zero is special right, because it's it's kind of furthest away from from its closest priority. I know it's a little harsh, but it's more explicit, I would say like it truly, is special. Now right.

A

I see what you mean, though I I don't know. I don't know if tim said that saying I'm not gonna merge it because of this or if he said it as a oh, I went and looked and everyone else does it this way. So we should too.

B

I mean the only were we asked to uh do some sort of a poll uh in the community or send an email uh to get a response.

A

At one point yeah, but I made the executive call, assuming we didn't have enough time to do that before and get responses before this deadline. On thursday that was like a week or two ago.

A

So we're here now um the the quickest way forward would just be to go ahead and flip. It leave zero as a special um and see what happens move on the only other way. I can think to remove ambiguity around making zero. A special flavor of policy is to um add a boolean or something right or add, like an extremely explicit boolean, which stinks because it's just another switch to configure, but.

F

Yeah I mean, I don't know who the uh the other casey is. Do you actually know him because uh yeah he's from red hat, okay.

A

um I have actually been talking to him about some of this today. um Okay, did he.

F

A

On that bit as well yeah, he did, he says he.

F

Would be okay with regular rules are priority from one to a thousand one being the most important one, and we signal that zero is a special value uh essentially so.

G

Okay, let's do that? Okay, I think.

B

G

B

Least resistant part forward.

A

Yeah, if we have.

B

A

I didn't see casey had commented, I think that's approval enough for me from the community to move forward with that.

F

Yeah, okay, yeah! I guess uh right now. Maybe let's do that. I I do have a pull request. I think I saw you have a couple of comments um and I do think the comments are about you know.

F

There are other things that we should have fixed in addition to that, it's not about what I have fixed so far right, if I'm not mistaken, so I guess a to me, I feel like uh a a good way is, might be that we merge this pr first and then you know you can you know maybe do another pr. On top of that, just to add to it, I guess: does that make sense.

A

um Or me I'm playing I'm calling after pr or not. I did that this morning.

A

I would just go. There was only a few things and I what I do is I literally have your changes on one screen and their comments on the other, and there was just like two comments: um okay, yeah. There was two little comments and then one about the um naming of the l4 selector that they didn't.

F

A

Right, um I probably if I were you just go ahead and fix those little comments in that pr and let's talk a little bit about the naming for l4 selector now, because I think that was the last big thing beyond the priorities.

A

Okay, right, I mean it'd be easier if we could just get all the all the comments addressed in in your pr yeah sure, unless you want to just finish it up with tim.

F

F

Maintenance is just a little bit choppy right now. Would you would you just.

G

A

It might be mine too sorry, um I just I just said if you want to go ahead and finish just just respond to the con comments.

A

In a different.

F

um Is it, is it just me or is it everybody else not here.

A

Let me see is that anything better.

F

But I mean anyways, I I think I, if I understand you correctly andrew, is that uh you know we can. I can um uh basically fix what uh we just update the pr as what you, what we had just said um basically have the power of these uh one being the highest precedence and uh xero b and special case, and uh we do the other naming part for renaming power for the lfo selectors, and uh I I can just update your um uh with those things and we should be good to go right.

F

Okay, yeah cool.

A

All right! um Yes, so what do you? What are we gonna do about the l4 selector? I'm.

F

Sorry um for the l4 selectors, um I think I do see a. um I do see a comment from the other casey uh this morning saying that.

F

We might want to do something like ports and he, I think what he did was propose a new sort of way to to do the oil processing. um I I guess we probably needed to uh take another look for that as well. Let me try to ping that comment down.

B

What was this l4 selector part which comment? Does this.

F

F

So essentially, we added a new l4 selector.

F

um This is because tim was saying that uh we didn't want it to do the same thing as network policy, where an empty ports means on all ports, because you didn't didn't specify anything and they want us to be very explicit so that you know, in addition to what we specified for the past lectures or namespace sector or whatnot, every peer should have a port explicitly defined and the the original proposal for him was to explicitly list out everything if we wanted to allow it from all ports.

F

So so, basically for every peer you needed to do like ports tcp. You know one two, six sixty three thousand blah blah blah and udp and sctp or whatever you can think of, and we're saying no. This is not the way to go, because that would be too extremely weirdly verbose and a lot of people don't actually even care about l4. They just care about three, and they just wanted. You know to select peers and expect us to work on all possible important numbers.

F

So we come up with this l4 selector, uh which is the thing that now you have to specify, along with maybe pass vectors and name space vectors, and we provided a enum called all ports which make people makes it a little bit easier for people to just select all ports if they that's what they want and if they don't actually want to select all ports if they are just caring about specific ports like 80 or 403, or something they have to uh explicitly put that in in the in the selector essentially.

F

But we are still maybe debating on how to do this. uh Exactly, as I see tim just responded, andrew just pointed out.

A

Hey yang, can you hear me better now? Yes, so yes awesome. So I was just saying tim just responded six minutes ago to this, so um I have it up on the screen. Can y'all see it? Yes cool? So let's see what he said, um yeah you you put into words exactly what I had said in this oops. Sorry in this comment above.

A

Wild cards are a little scary, but.

B

Yeah we're running our names to name fields.

A

Because we've become extremely explicit in the world.

B

This is interesting. I I didn't see this. uh What about.

F

So I I take the mayor, meaning that he didn't even like what he wrote about the second one, because because the second one is the closest to to our original proposal yeah, we just wanted a different word for ports on the second level right essentially um well, it's.

A

Not even that we wanted a different where yeah a different word for ports on that top hierarchy.

B

Can you guys consider like l4 ports or policy ports for the top level, all right.

F

I don't think he liked the word out for that's the problem, so.

A

What if we have.

A

Why don't we just update the api for admin, network policy port and instead of adding like an extra layer, just have an all ports field within admin, network policy, port? And we say if that field is set. None of the others can be set like. Isn't that the same concept.

A

Does that make sense.

B

I think that's a little weird to validate because that's a list, so if you have one part with all ports and then another list item with some without the outputs, I don't know how much sense that would make fair enough.

B

B

Let's just pick one, I guess and then continue as soon as I suggested, and if we, if we find a better name, we will comment and be updated. Well,.

F

If I have to pick out pick the second one that he just met.

F

But you know it to me: yeah.

D

Because that would be the easiest.

F

Update too, yes, that to me that works, it's just that the naming doesn't read, isn't really sounding great, um but but this works right. It's just.

A

F

Yeah I'll just pick the second one: let's throw that in and see um see what.

C

You know not to pour like more confusion on this, but I guess the second one says that you, if you say all ports, you're, also saying all like it's all ports and all protocols right, yes, yeah, okay, we don't want a way to say tcp everything but udp only.

F

So if you wanted to do something like that, you you'd have to go with the best way. So the all ports is just a like a sugar to for people to get around when they don't really care about l4. When you, when you wanted to specify some ports for a specific protocol, you're, not actually not caring about l4, you do care about l4. Now you have to go to the very explicit way to basically just sell everything you wanted to allow for ports and protocols. uh You you can you cannot just do sugar anymore.

F

So that's our original reasoning for this. um That's fair enough. That makes sense.

A

And you can still do you can still do that royal. You would just have to specify a port with a port range. It's super wide. It's like, then. It's still explicit. You know what I mean.

C

A

Yeah, like number four down there.

C

Right yeah, one to sixty five thousand yeah.

A

Okay, well, I do need to hop off um yang. I think that's a good idea. If you get that updated, I'm actually gonna be working pretty late tonight. So I'll get it looked at and probably merge tonight, and then I will, I guess, push a p another pr to address. John bellameric's comments. He's the production, readiness review approver, so, okay,.

F

A

He had a couple of comments as well.

F

Okay, sure uh I'll I'll fix what you have commented there and I'll incorporate this and the other power of the conversation into my pr and I'll ping. You one of them.

A

Okay, well, we are almost there thanks, everyone, so much for the help. um The last little bit on that kept is, I think, gobin still hasn't signed the cla like if it comes down to it, I'm just gonna punt his commit from the kev, um because I don't think that commit is even relevant anymore. um So yeah.

G

A

Give them until tomorrow afternoon to do it or I'm just going to get ci green on the cap, because I don't want that to block us.

F

Okay, that makes sense to me.

A

Cool okay, we're down to the wire um thanks, so much for all the help, thanks so much for everyone coming today, it was a really productive meeting and, um let's see how thing goes, things go this week, have a good one.

C

Awesome thanks all.

F

Thank you, bye.