Kubernetes SIG Network, 6 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Meeting for 20230606

Description

Network Policy API Meeting for 20230606

A

So, hey everyone welcome to the Sig Network policy, API Upstream, kubernetes meeting it's the 6th of June 2023.. Let's all follow the kubernetes world of conduct and be nice to each other. Let's get started with the thin agenda that we have for today, but before I go on with the agenda. Is there?

A

Are there newcomers in the participants today in the team meeting who would like to introduce themselves.

A

I guess not, so let's go with the agenda, and so there are some PRS that are up for review on the repo and I.

A

Think Yang was working the other day earlier this week on trying to install the adminator policy and Baseline agricultural policy apis in his cluster to work with Andrea, and he run into some issues and he wanted to come up with some documentation that can help users get started easily on the process of installing the crd on the cluster, and now that we have a released version of the API, uh our first release, which is the 0.1.0.

A

It should be easy for people to just get it from the from the raw GitHub uh actions thing and then just to keep CTL apply, and that should work and I think this is the installation for that and I think there's a nice developer preview of how this looks like under the guides and getting started. So if any of you are interested in doing reviews, it's kind of an easy one and I think this is nice to give it some thoughts. I've left some comments and I think Jan will get to them.

A

So that's the first PR.

A

Then I think the second one was something that I added I was trying to get the implementation in OB in kubernetes, for the admin Network policy and I noticed that we have support for status in ANP, which we didn't have in network policies, but I think the status is the matter of even conditions. So it's it's not really standardized in any way, and it's the implementations have the freedom to choose what kind of status they want the set, which makes sense.

A

We got our whatever their logic is for implementing uh the policies, but um I thought it would be. It would be nice for us to also print that in the OC get output command for both Baseline and admin, so that users can leverage back from the status without having to do like a full describe of the policy. So it's also a very smart and new change. So if anyone wants to click on get it, you can get that in before the next release. What.

B

Does it do if there are like multiple statuses or multiple conditions.

A

Yeah I think it would print the first one, because.

A

Because it does this the star thing and I've seen it usually with respect to other CRVs. What I've observed is usually picks the first one, but that's a great question. I think I should double check.

A

Okay, you want to come into.

A

Any questions on that one before we move on.

A

B

It's not um I've.

A

Been working on the conformance tests still I think what I'm going to do next is so there there's been a lot of PRS that are floating around with the new tests, but just to ensure that we are um on track in in real, like these tests are kind of helpful for other implementations, also I'm kind of waiting on Yang to give initial feedback on the existing tests that we already merged and to see if those are also helpful for Andrea and not just for obn kubernetes, so that we have some kind of um an agreement on the framework before adding more of them.

A

But I think the one thing that I would really get try to get in is the Baseline at the network policy conformance, which is just basic tests, at least so.

A

That I can then leverage that for my implementation, Downstream but I'm, trying to kind of hold off on adding newer tests till we have at least some initial feedback from from the Android Force, also on on what they think about it and then I think I'm also going to add some documentation for conformance tests, so that other contributors can also know the general framework and how to move around with the code and what kind of tests already exist today and what more tests we need to add in the future and out of the issues that we had.

A

uh Let's see if you were, if anyone is looking for for help around contributions and how they can get involved, I think if you click on the area conformance label, there are a bunch of things that I've opened, that we can that I could use help with or even the community could use output and be careful I trade over there. If anyone wants to volunteer group pick these issues, that would be great, especially with this one.

A

The we have a poke server utility that we use for the tests, which basically does an end-to-end checking right is the connection reachable or not, with the existing policy in place and I think we can really improve the parts because it was just the first version of the iteration server.

A

If there are volunteers and if you have Cycles, please do take a look at this one. Foreign.

A

I actually added this item for admin, Network policy, especially with logging it, but around debugging in general, right I, don't know how other implementations are doing around this, like for Network policies, at least in openshift being and in obnk. We have a specific annotation that we do for namespace I'm, not sure how other plugins handle this uh do any. If you know- uh and if is there is this- is this something that should be more often Upstream option that we should provide? Or is it something that's very implementation, specific.

C

I can't provide, oh sorry, go on.

D

Oh no go ahead. I was gonna, provide some context from the gke side, but.

C

I think that would be better at first.

D

uh Sure yeah so I mean on gke. uh We have uh Network policy logging as well um and yeah. We support either a annotation on a namespace um or we have our own crd, which uh you can just use to flip it on cluster-wide, so you can choose either turn it on for the whole cluster or opt-in, individual um namespaces.

C

Yeah I wanted to uh just discuss it in general uh because when you so first of all uh developers and like namespace owners, they will be able to see which network which admin Network policies exist in the cluster right.

E

So question hope I turn on the camera. That's not what I want. So, if you do logging, which is great, will you also look at specify a sort of Primitives, counters and stuff like that, then different, sort of metering.

C

Do you mean in Downstream implementations, there is no way to do that. No.

E

No yeah yeah I'll sort of expectations.

B

Yeah so like different plugins may have different abilities here and so I guess. We'll definitely want to look at what different people are doing on their own for Network policies and see if we think it makes sense to try and have a standardized way of saying it in admin. Network policy um or we may have like a standard way of requesting logging, but with no standard definition of how the uh again implements it.

E

Yep I just wanted to understand, but I mean it matches with what I thought yeah.

B

No that wasn't really a response to you, even though it's sort of a in.

E

General, no, no! It's like a sort of it's hard to log to log when they don't own the implementation right.

C

Vlogging right because, if you're a namespace owner and something is dropped by admin, Network policy uh and not by your local network policy, you probably may want to know that like to debug. But then yeah.

B

Yeah no yeah, if it is, it would only be usable by the Admin.

C

Yeah but well that makes sense, but then also how uh namespace owners will be able to see which network policy drops their packets. Let's say.

A

I, don't think the namespace owners will have that Insight. If the drop is passed by an admin Network policy right, they will have that Insight only if the drop is cast by the network policy on their namespace.

C

Yeah but that's gonna make debugging sound, more difficult, Maybe.

A

Do users of the cluster usually do they have rights to debug? The cluster I thought it was only um admins clusters. Cluster owners operators.

C

A

C

I mean when you have logging for Network policy, then every Network policy or namespace can have this logging enabled right. So then you can but.

B

But the logs go somewhere where only the admins can see them, because that's.

C

Actually, a feature.

B

That was added to network policy because there was no admin, Network policy.

E

Exactly and that's why I asked about metering, because that's typically much more available to see counters I mean allowed connect allowed connection which we call them or blocked connections, and so on.

B

We had talked at one point about like possibly having some way that you can figure out conclusively. Yes, my packet is being dropped by an admin, Network policy. You wouldn't be able to figure out what the policy said or why it was dropping. But but, like you know, we could theoretically add that functionality somewhere um and then at that point you know talk to your admin.

D

E

D

A quick question about something you said you said: logging is an admin. Persona thing. Is this something that we've like defined somewhere or is this something you're proposing.

B

So well I mean specifically, you know. Nadia was I, think mentioning about the position. There's no standard logging for Network policy right, but the thing we added in OB and kubernetes. We added that because administrators wanted it not because you know end users wanted it so the way that it logs the logs go. You know into some node level thing that only the admins would have access to. So, even though you can enable it on a namespace basis, it's not something that is usable by namespace admins. It's only usable by cluster admins Ico.

D

B

This is like an open. This is.

D

An ovn in particular yeah, okay, I, understand. Thank you.

C

But also before, when we only had namespace Network policies, you at least can list all of them and see which network policies exist so that you as a namespace owner you can like at least imagine what can be dropping a packet stand with admin, Network policy.

C

You may not know that at all.

B

Right but, for instance, if the cluster administrator creates firewall rules with IP tables or or creates egress firewall rules in openshift, you have no way of finding out about that either.

C

Yeah sure that's how it's implemented.

E

Looks like under five volt might not even exist in the cluster I assume it'll almost always will, but doesn't have to for anything that goes out right.

A

Yeah and I had a question for Rahul, so you mentioned in gke. You use either uh crd for enabling it on a full cluster-wide level or on namespaces using annotation, and that namespace is using. Annotation is rpd1ov and K. Also like Dan said, though they don't really have a way to do it on a cluster wide level. But what about ANP um well? Do you have support for admin policies Downstream there or.

D

um Unfortunately, no we don't have any ANP support on gke right now.

A

Okay, yeah like, for example, The annotation, seems like a common story, so maybe that that is one thing standardizable, but again for A and P. It might not be on an age-based level, but it has to be on a policy level. Okay, so yeah.

C

It may be difficult to decide how, like this logging, as a part of API, should look like, because it probably May provide different options of what like, if you only provide, enable disable logging or if you allow log levels uh where maybe there are some more options for specific implementations.

C

Yeah that may be difficult to standardize that.

A

Yeah I mean I think that is a valid point that does depend on each implementation and exactly how the um convert the inverse and Ingress roles in their implementation on how the login makes sense for them. So maybe it is hard to standardize, but.

A

Yeah just wanted to bring that up to see. You know if there are ideas doing this upstream or if we uh at least an OV and K, should take care of this Downstream again.

A

All right sounds good I think uh that was a good discussion. Anyone wants to add something to the logging topic, for you know, long-term audio's item.

A

Okay, an audio over to you.

C

Thank you, uh yeah. That's just a continuation of that um conversation about what's the best way to express tenancy in the most simple way that covers all of our cases.

C

um I have added one more option there, which adds a completely separate object for that uh I think it would be nice to hear some feedback on that in general, uh if I, just summarize that there are some field. So when we talk about tenancy, uh it seems like our use. Cases only need to Define tenant to tenant relationships.

C

So basically, the only type of peer that we may have at this point is same or not same tenant and like there are no other ways to say anything that would make sense and then so, based on some of the previous uh versions of uh assertive that then added. It also has a namespace selector that basically defines which name spaces are considered or like a subject for this tenancy and then same same labels.

C

Field uh just says how this that, how this namespaces are split into tenants based on which labels and that also solves one of the problems we discussed about what we want to do for empty labels right. So, if you don't want to consider label, let's say user that doesn't exist. If you don't want this namespace to be a part of a tenant, you just add this exists, selector that will avoid that and then in case you do not add it, there will be a separate tenant that has empty user label.

C

So I guess in general that like simplifies again some of the problems we've already discussed, there are two like Corner cases on this.

C

One thing is that uh this, if that's a separate object, it needs to be probably in the same priority range as admin Network policy, which is kind of the same as it was before, but uh from the semantics point of view, but it will mean that we have two different objects that operate on the same priority range and then another question was: if we uh need to in case we end up with this object.

C

Do we need to have Baseline admin, Network policy, tenancy thing which will be applied after uh Network policy and they think existing BNP API allows tendency, but then I thought about that. A bit more and I couldn't find a use case where you would like to imply tenancy on BNP level because it may be overridden with network policies. So it doesn't make a lot of sense.

C

Yeah, so that's a recap of what this change was about.

B

Oh yeah, oh I, think there. There is one use case which you know: maybe it didn't get written down, but I know it's something we talked about, um which is the admin denying all egress by default in a baseline admin, Network policy and then well, although I guess, maybe that that's not really a tenant thing, though that's just a baseline admin, Network policy thing so yeah.

C

B

Well, I guess if you want to have soft tendency right, so the the admin creates a rule saying you know no communication between tenants by default.

C

Yeah I I actually thought about that and I uh tried to think again about what every uh object means in general right. So when we talk about admin, Network policy, that's something you enforce as an admin unless you use some product namespace labels, but we can talk about that or some labels. You do not control and then Network policy is like the developers desire to secure their namespaces and then, when you fall down to Baseline admin, Network policy, that's just the default. Network policy object for namespace, basically because it is completely overridable.

C

So I I'm not sure if there is any other use case for Baseline admin, Network policy, except for it to be the default Network policy. In case you don't provide anyone a one or in case you want to just add some more Rules to This default. Network policy.

D

Can I ask a more high level question and I apologize? This is probably treading old ground because I've missed a couple of these meetings, um but is there a tldr on what the goal would be for this new tenancy uh construct like, however, it ends up shaking out? Is there is it because we want to express something we can't in enp today, or we think we can express it more simply.

C

Yeah it's more of a second option, and there are. There were some slides that they, um when I tried to explain why the existing API may be a bit uh confusing or maybe allow more options that we actually need, so that in general this is a an effort to simplify the existing API.

B

B

Was starting to implement this and it was like you know.

B

Why can you do this and you know why does this work this way, and so there are a bunch of conversations about it that led to the the realization that we we added tendency to admin Network policy in in a way that is much much much more flexible than you actually need for the user stories we have, um and so we thought you know, maybe we should rein it in before people start doing totally insane things and you're forced to make your implementation really uh like inefficient, and you know to support all the possibilities.

C

Okay, I know the questions or comments on that.

C

Okay, uh I think that we can uh keep this discussion in the dark comments. Thank you.

A

Yeah, it sounds good I think we've also attached the document to the agenda so and I, and thanks Nadia for linking the presentation here which we which she had done a few meetings ago, which kind of outlines the difficulties around same and not the same labels and like Dan, mentioned how we can Define it in a way that does not give so much of freedom to express relations uh but yeah.

A

Let's keep the discussion going around that one and see if we can control consensus on how we want to do that, at least uh for the next version of the API yeah. The next major question- and that's really all we have on the agenda. Does anyone want to bring up other topics, discussions, questions, suggestions.

A

Going once twice and sold so thanks, everyone for joining the meeting today have a great rest of the day. Talk to you all again in two weeks.

C

Thank you, Surya.

D