Kubernetes SIG Network, 15 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Network Policy API Bi-Weekly Meeting for 20211115

A

uh Hey everyone today is november 15 2021. This is a meeting of the sig network policy, api sub group, distinct network. This is a cncf certified meeting. So please be nice to everyone and let's have a good meeting today. So um just getting started really quick. There was one issue that got assigned to us. um I was taking a look at it before I put in the agenda and I'll share my screen real quick.

A

um It looks like it is a more of a calico question, so I was just going to ask them to reach out to calico. Basically, um a pod is failing. If network policy is there, so not really something about something that we're controlling um more on the cni side of things, but if you're interested you can take a look at that.

A

Cool and I was catching up from last week- I wasn't here- is there stuff regarding uh cmp that we need to go over in this meeting or are we just working to present to signet in the next sig network meeting.

B

Not in particular, I think, uh last thursday there was a sig network meeting already and in that specific meeting they decided that the next occurrence of the meeting, which falls uh right on uh thanksgiving uh that occurrence will be cancelled. So we won't have a meeting. You know uh next next thursday, uh so we presented the you know the cmp updates. Roughly. You know the very condensed version of the updates to the sig network, because you know there are other agenda items that took a lot of time and then you know our.

B

um We basically presented that you know there are five major updates we made to the cmp cap or five major areas. We wanted um some uh feedback on. um I think it was uh first of all, you know the plus network policy naming should we rename it to our policy, for example, and uh do we want the priority number to mean? You know a lower powering number to mean higher power, your lower priority- and uh you know the the struct, uh the the workload selector struct uh about.

B

You know how the fell, open and fell close thing. uh How should we design the workloads like so? Should it be the enum or should it just be? You know the selectors and uh I think the other things was uh is admin. Is that the mission control for um no same power, the um between or among cmps, is? Is it okay?

B

So those are kind of like the questions we brought up to the sig network and uh um we asked them to provide feedback on the cap, because tim um specifically said that you know those are really good questions. Those are questions that people needed to think about before you're gonna jump into conclusions, so they don't want it to sort of like give an answer to these questions on the spot on the same network meeting, but they said they will.

B

You know, uh review the cap and provide a comments there, um but you know again this might slip on their minds, so I plan on you know doing a quick painting on on them again. You know sometime this week to uh remind them to uh review the latest com commit of the state uh of the cmp uh uh cap, and uh I I think that's it they're not too much use for feedback.

B

We we did get on the on sick network meeting, but so we're hoping that there are some sort of a common newcomers uh from this week or the next. um Regarding the latest updates on.

A

Great awesome, thanks for filling me in um sounds good to me. Is there any burning action items that need to get done? I gave it a quick review today. I didn't see anything major right off the bat.

B

Yes, so I think I think ab sheck has uh some uh minor comments regarding the pr that we merged before the signal, because remember I had a pr that we wanted to merge before the we're meeting on thursday and.

C

B

Didn't get a chance to review it yet I think he has some minor comments on uh on that particular pr, but I think uh um those we can sort of like address it asynchronously.

B

It's not something really major, so, okay, basically just some nits, so yeah.

A

Cool sounds good to me. um I guess, then the plan will be to to ask for feedback before the next next sig network meeting then, which I guess would be in december: um cool.

A

Okay, um that's all I have on the agenda. Do people have questions, concerns ideas, anything they want to ask.

A

Is the work still ongoing or is it barred on cmp for service? The service, like the selector proposal and the um fqdn proposal, is that are those those google docs being worked on? I know uh vinay was working on him he's not here today.

D

I can give give a quick update andrew, um so I think fqdn we are working on it service selector. I think uh we remember. We said that it's going to be part of network policy v2, because um like right now it failed open, yeah.

C

In order to plug that thing,.

D

C

We need network policy.

D

Okay, fair enough, but but I think fqdn is like more. I would say like uh it's more priority because we like we don't have the failed operation there. I mean because I think, like.

E

Things will be only referenced as a remote.

B

E

D

So it doesn't run into failed, open issues so like we can make progress on that without waiting for net of policy meter.

A

I mean how do you not run into the same issue right if someone provides a you're saying an fqdn peer, um but the cni doesn't know what that that is.

D

Right um so on the like, so we have name space, selector and part selector right I mean like you can um like. If I, if I have just name space selector and then I don't specify part selector, it would allow all the parts right is that what the current behavior is.

A

If, if you yeah, if you just provided namespace selector and not pod selector right.

D

Right so I think if we add fqdn uh yeah, I think oh it might uh like it might interpret as like opening all the opening all the namespace workloads. I think yeah. I think it yeah. It would still run into that thing. Right.

A

And it depends on.

A

This is like of fqdn is kind of a complicated object. We have a implementation of it in openshift um and you know there's a lot of different constraints about how often you update uh dns records, like like there's a bunch of questions around that, um and if your policy is for some period of time resolving to a wrong ip like things can get pretty messy. um I don't really know the best way to do it right now, um but I guess we'd have to think about it for a little bit.

A

I know vinay had shared that document. He started that google doc a while ago. I need to go back and look at it right right, so I think.

D

One more comment about.

A

Fail open is, since fqdn is not.

D

In the target, so you don't, I think, there's.

B

You don't apply the policies to.

C

Parts that should.

D

Not have been applied so from that perspective, it's a little bit less severe right. I mean because if I, if I spec.

D

Than it should have, but only from the same namespace, um okay yeah, but I think yeah, but again, like your point about thinking uh like how we're going to upgrade the records, uh how we're going to convert the dns to ip addresses, because I mean that ultimately say provides rely on ip addresses right. So all right, we need to figure that out. Like I mean that's it, that itself is a complete. uh You know like uh separate topic on itself like it requires a lot of thought process.

D

I think uh other than dealing with the failed.

A

D

A

Just a little worried too, like with that with you, know, upstreaming something upscreen upstreaming an fqdn policy without specifying exactly how we expect it to work, and then I feel like we're. Gonna have an upstream feature: that's behaves differently across cni's, which isn't, I think, a great thing right. It leads to user confusion um and and it's a good argument for per cni specific resources rather than upstreaming such a thing right.

A

If, if every cni has a different behavior for fqdm policy, then um then you know, what's the point of upstreaming it now, if we can figure out some way to standardize uh behavior across the eyes, I don't know how to do that. Yet I think about it for sure, then we might have an argument for it.

E

A

E

Andrew, can you can you clarify the concern a little bit? Are you? Are you concerned that we won't be able to reach a consensus among cni providers or that they're just like things that we haven't explicitly called out yet right? What's.

A

What's the major concern, I think you can, you can argue, like I think, you'll be able to reach a consensus among cni providers that an fqdn policy would be great right. um The problem lies on the other side of it. um There's a lot of different ways to implement fqdn and dns is a finicky beast in the sense that I don't feel like the behavior is going to be consistent across cni's for an fqdn.

E

So your concern is that uh so the concern is that, even if we provide an explicit specification, it's unlikely cni's will actually adhere to that.

B

Well like, if I may, uh I wanted to you, know, provide some. You know quick insight on this, because I actually um before my before my leave, um I actually implemented the our flavor of the kdm policy in entry. um So essentially, what we we looked at is that we also look at the cdm solution right, which is open source and the catechol solution is closed source. So we don't know for sure.

B

You know how they're handling fqdm policies, but I think that one major problem you know regarding fkdm policies, as as andrew mentioned, that you know we there might be a lot of different schemes in terms in terms of deciding how long I guess a particular dns record can be hold up being called up to uh so in our solution, you know. First of all, it depends on you know which dna dns servers, you're you're talking to. Is this the um dns server configured for a specific pod or you're?

B

Just using you know the the kube api coupe dns, which is configured in the cluster, because you know in the in the cluster, you can have different dns policies for different parts. So if you have a policy applied onto different parts, then if those parts are having different dns policies, then you have a little bit of confusion in terms of which dns server. Are you actually.

F

Looking looking to resolve, are you look? Are you tracing all the way that way down and try to look at the time to live of the actual server? That sort of is responsible for the domain and the address that you're looking up or.

B

uh Right now we have it as a configurable option, but uh I don't. I don't think we. I don't think we actually um made it uh as uh as I don't know as uh specific as you know, if there are different parts, then we look at each part's dns policy and do different things on those parts. We didn't go that far.

F

I think, on the other side right, they have something else that can be updated. That's out of your control. What.

C

F

Things are resolved too, because when you build it all the way so that you get when you get an address, you try to check back, because I assume that when you, when you have the address in the field right, you don't try to map it back to to the name, to a name by doing a reverse uh name: lookup. That takes too long time.

B

Yeah, I no, I don't think we do that.

F

B

Do you know, as you mentioned, you know, we do take into account uh ttls for sure, and you know our scheme right now. It's a pretty simple one is that you know when we uh for a certain record for a certain name right. If we.

F

Actually read the ttl, then we proactively.

B

Just you know query that.

F

Name again, I'm just scared. When you have things like you see what hashicorps have done and so on, when they basically do their service register and the pods go and register themselves so that you can get systems with really really high frequency updates on. What's in there I mean, so I don't think it's probably for most of it, because it's probably to reach fairly stable domains right then these fqdans will work fine, I mean google or something like that.

F

They don't change the name resolution very often, but I think there is needs to be some recommendations that you do this to very stable.

B

F

Have to address.

B

They have you know those you know floating ip stuff where.

C

B

You actually do query on different dns servers. Then, usually you get different ips for, for you know, for example, google.com or facebook yeah.

A

That's that's they're, not actually. You know.

B

On different regions and.

A

How the packet gets there yeah so yeah. That's that's kind of my that my worry is like there's a lot of ways to skin the cat here and on the implantation side of thing, and I think the the minute behavior aspects of it are going to be different. So.

F

Layer 7, this plus stuff works perfectly for right, because then it's part of the url right, but.

B

Yes, yes, but I, but I feel like most implementations um as of now, for example, cdm and I think uh and try at least we were. This is still sort of like an l4 solution where l3 r4 solution, where.

C

The domain name is.

B

Actually translated to addresses, but if it's actually level 7, then we don't have the problem right. No.

F

A

Right but that that's a pretty big sell it's the same with openshift. It is kind of a pseudo, no.

F

No, no you're saying it later save and you don't have a problem, but I do think that in layer four, this will never be perfect. Yeah. uh The question.

C

F

The question is: really: you have two fours like one is like when you block when you don't allow uh things that should go through and that's probably more common than the other way around right. When you will block when you will not block things that should uh be blocked, because that's typically, when you have an address, that's changed to be used for something else right, but.

A

So, point being, I think that you have two cells here right: either: cell cygnet and us on a you know, adding layers, pseudo layer, 7 support to network policy or trying to build this into a new object that you know has layer, 7 support. So with cmp explicitly.

A

We are focusing on east-west traffic, and my future mindset was to have another object that would serve solely to act as a moat around the cluster so solely focused on north north south traffic, rather than having a single policy to handle east-west and north-south.

A

That might be a better place for something like this to live, um and then I don't know, that's just my opinion but, like I said, I'd like to look at the documents vinay's already put together and think about this, some more, but this has been brought up to sign network before and they're their biggest.

A

This kind of embodies their biggest problem with it like they didn't want network policy to be layer, seven so shouldn't.

B

Yeah, so I don't know if those discussions sort of answer, your question.

F

I mean, I guess you could describe it as I mean in one way as a helper object that will translate these uh dns strings into set of addresses and that it runs with a I mean if you describe it, that you don't have to implement it. That runs with a certain frequency and it takes the values that it's given at that particular point in time. It's it's a helper for lace. I mean it's not perfect, but sort of the.

F

I think the most important thing is to describe the semantics so that there are no surprises uh and then, if you use it well, then you have to accept that there is that there are glitches.

E

Right that was going to be my question like is it? Is it maybe what we can do is we can say open source? The open source specification is a pretty like bare bones version very similar to what you described, which is you know it does it all that open source requires for conformance is all right.

E

We do a lookup, it's meant to be really for you know, you don't want to type out an ipv6 address and it you know, you know you know it's not changing, and so it's a helper, but you know, implementation stuff can be as sophisticated as cni's want right like if you want to do ttl or you know, periodic rechecks or whatever the case may be. I guess individual cni's can yeah.

F

Or you could also be lazy right if you do a firewall, if you do a reverse lookup and get don't get the positive answer that you would actually block the flow, I mean, if you have some sort of you get, you do one check first and that you let it you let the flow establish, but you you run more checks and you would remove it if other checks are not fulfilled, there's all sorts of things you can do in sort of the non-uh sort of non-standard.

F

But that's also something.

C

F

Think do you know if the cni 2 discussions have started yet I haven't checked over there.

F

I do think for the cni that to to sort of have the discussions around the let's call it the the connectivity piece, that's sort of set up to connectivity and the path, the policy enforcement point and the policy uh decision point right can that be built in there so that you can have different uh policy decision uh functions, basically working with different cni's or different connectivity pieces, because today I mean, if you look at palo, alto and so on, they have to do a full cnr implementation. So it's like why they're doing firewalls?

F

Why would I have to go in and do a yet another kubernetes cni?

F

uh Now they add, do it as uh as I mean what they call them uh chain, loaders right, but they still go in and do stuff and they have to send all the data up to and stream it up through yet another pod, so that you really do impact the uh bandwidth.

F

It's quite significantly. I think that's also something we could look at as part of the version. Two so also try to get the cni to be more firewall friendly. I mean the layer, the lower layers, not layer, seven, because today it's all baked together and if, if you want to do one part, you have to do everything and that doesn't make any sense to me.

A

Yeah, I want to think on this a little more too. I I've posted the working document. That's already up um from a on the agenda, so that'd be a good place to write, notes and think about it.

A

Some more, you know we keep coming back to it as well, like I think, you're still going to run into the problem, you will with trying to add anything to network policy is if we could figure out an intelligent, uh well thought out and agreed upon way to report like we don't have our core versioning, but if we could figure out a good status or a way to report what our cni is doing, um I think we could get around a lot of these fail, open, they'll, close questions um so again, if anyone has time or the bandwidth or wants to take that on, it's a really muddled and hard hard one, but I think it would be really important and I just haven't had a chance to get into it.

A

To be honest, so.

A

Anyway, are there any other questions? Sorry rahul. I know we kind of meandered around your question.

E

No, I mean this. I think this was a perfect discussion. um It captured a lot of yeah what I was thinking about what I was trying to get clarity, yeah.

A

Cool anything else from anyone avashuk, I saw you hopped on. We touched on cmp a little bit, but uh nothing too major just responding to some comments. You had on yang's pr and uh just trying to give it a couple more reads, even though I feel like I've read it about 10 times now,.

C

Yeah I apologize- I I didn't get to that pr early, uh but I left some comments uh after it was moist.

C

Is there anything that is depending on me? Let me know as well.

A

Will do cool anything else from anyone.

C

Could we change the the cnp meeting do bi-weekly, or did we add that in the gender notes I will just copy the link and invite myself.

B

Yeah that wasn't me I I uh I was uh scheduling that zoom uh meeting and I think my outlook client is uh some somewhat buggy, so I thought I sent them, send the invite to everybody, but I I think nobody received it, um but the zoom link is uh for the for the, for the sake of the meeting is, is actually bi-weekly, so I will try to you, know resend the invite and uh so that you know everyone can have a have it just click into their calendar.

B

I'll, probably do that after this.

C

Okay, oh yeah I'll just create my own uh uh invite on my own calendar so that the time is blocked. Yeah, I'm going.

A

C

The one that you send, or in slack.

A

And is it bi-weekly starting this week or is it next week.

B

uh It will be next week, um so I was thinking that so maybe we could have it. You know always align uh to be before the sig network meeting uh on the thursday, because you know that way we can go over last minute to if we wanted to present to sig network. uh If there's anything, we wanted to present to seek network and go over not right before the meeting and stuff, but so, if you guys think we should do on the on a different week than a sick network meeting. That's fine with me too.

A

Nope makes sense to me.

B

A

C

To my calendar yeah, I think a bunch of google docs have the probably have the old zoom link. Maybe we can just update them to the newer one sure, thanks.

A

Okay, anything else, questions comments, concerns.

A

If not we'll give everyone 20 minutes back, I'm still always looking for people to help me with the repo add stuff, um the one issue we had to import all those user stories, uh the person who was on it I reached out and said I think I finished that comment. I was going to reach out and just say we're going to sign this to someone else. If you aren't able to get to it here soon, but otherwise love to pretty up that repo. So yeah, that's all I have.

A

I hope all of you have a really good rest of the week and we will see you here soon.

F

A

Awesome see y'all. Thank you. Bye.