Kubernetes SIG Network, 21 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Network Policy API Bi-Weekly Meeting for 20201221

A

Okay, so we are now live. This is sig network network policy. Evolution sub project today is december. 21St 2020.

A

I kindly remember you that this is a cloud native kubernetes community meeting, so we have running here the code of conduct, so please be nice with each other, and the agenda of today is dedicated to folks that have been working with the cluster scope and network policy to present to the to the rest of the sub project to this meeting what they have been through so abhishek- and this is with both of you.

B

All right, thank you, ricardo! Thank you, everyone, um first of all, can you guys hear me well and see the slide.

A

Yeah, actually, we see both of them the slide deck and the presentation. The next is like.

B

Oh okay, let me fix that.

B

Is this better yeah, yeah? Okay?

B

uh So yes, uh first of all, thank you for giving this opportunity to talk about the cluster scope policies, uh as you all know that you know we have been collecting user stories across everyone for for network policy evolution and some of those user stories are kind of aligned for administrators and kind of demand, a new resource.

B

So so a few members within the network policy, api team uh started exploring how to solve that uh problem, and so I want to first of all thank uh you know a lot of other people who have also contributed to not just the proposal, but also to the slide deck uh gobind, johar, yongdae, christopher luciano, vinay, bennett, satish, mati and jangli, who initially also did help us in this proposal.

B

So a big thanks to all of them. uh The agenda today is that we're gonna look at uh first of all, why we need the cluster scope, network policies and, uh and then they use some of the use cases that demand this uh this resource and then we're gonna. You know discuss uh through the proposal.

B

uh Also, then, we'll do a little a little bit of deep dive with some of the you know proposed fields which which needs more attention and eventually we'll go through some sample examples and finally, some to do actions and you know, get feedback from everyone.

B

So hopefully this will be a more of a back and forth between us and you all asking us questions and discussions so feel free to interrupt at any time, and I do expect that this may go or span on this presentation spans over multiple sessions so feel free to stop us and ask questions and I think most of the other team members are, you know, because of uh holiday season.

B

They are not here, so uh it's just going to be represented by young and me so young feel free to uh stop by, and uh you know.

C

B

uh Thank you so feel free to you know, interject, and you know correct us and or respond to uh questions all right. So, let's first take a look at uh the the reason why we need uh cluster scope network policy.

B

uh Essentially, what happens is that you know we have multiple personas today that exist in a kubernetes environment, the developers who responsible are responsible to define services and their workloads and are kind of name space code, perhaps sometimes overlapping namespaces as well, and then there's another persona which is a which is that of a administrator who's responsible for the maintenance of the cluster and has in general, higher privileges and authority than than a developer, and sometimes a cluster administrator needs certain strong guarantees about the behavior of its network.

B

And, uh and so what happens is that today in kubernetes we have a network policy resource which is mainly developer, focused apis. So uh generally, what we have been seeing is that, whenever you know some administrator oriented feature uh ask is made, we kind of you know, push back saying that the network policy is meant for the developers, uh so the evolution of network policy- you know maybe- and it takes a while- and perhaps some of those use cases are not addressed.

B

So that's one of the reason why we we need a new resource which, which is you know, complementary to the network policy resource the network. The clustering method administrators also want to you know, sometimes deploy these policies uh for the entire cluster.

B

You know as opposed to just the namespaces or maybe copying it all over the different namespaces that are available, and they also don't want a developer to you, know, intentionally or unintentionally, override certain security guarantees that a cluster languages administrator may want to have.

B

So you know- and our back also doesn't really help that much, because you know our back tries to solve a different kind of a problem uh as opposed as opposed to what network policies or security policies intentions are so um so that kind of like leads us to the need for a different resource, which is a which is on a cluster scope and specifically tailored for administrators.

B

Some of the use cases that we collected- and these are not limited to these, but you know just uh something to highlight uh what we've collected over you know over months of this activity that this group has done. uh When I said this group, I mean network policy, api plus plus meetings that we've been doing since the beginning of 2020..

B

uh I think uh you know a lot of uh people want to have the ability to you know.

B

Let me back up uh administrators, sometimes um or communities clusters sometimes are multi-tenants, so you you want to allocate certain namespaces to you, know, tenant a and certain other name, spaces to 10 and b and so on and so forth. um Then, in that case you know having a a security guardrail- or you know, as a security aspect, that these name spaces should not overlap. But you know these traffic from name space uh for tenant a should not cross into traffic or distant for name, space or tenant b.

B

So there is a need for uh some some sort of an intra name space allow and denying the inter name space traffic uh it.

B

It can be achieved with kubernetes cluster network, sorry with kubernetes network policies, it's just that it needs to be repeated in every name space, and on top of that you know the developers or the tenants have the ability to override uh these uh network policies by uh adding a namespace selector in there to from, and then you kind of uh do not guarantee these things in certain cases uh for every kubernetes cluster, an administrator may want to. You know, allow certain traffic uh by default or, as a baseline.

B

You know most pods that come up or most services that come up. They would want to talk to the cube dns uh or core dns pods uh that exist in your kubernetes cluster and they probably reside in uh one name space and not probably spread across every name spaces. So these kind of baseline rules need to needs to be enforced. You know so just guarantee that certain connectivity is available in certain cases uh you want to restrict.

B

You know certain ciders, which you know. Probably the workers should not talk to, and perhaps in certain cases they want certain ciders to be accessible. So again, this can be done with kubernetes set of policies. It's just that with. As a cluster administrator, you can give that guarantee to every name space that comes up dynamically instead of you know, having to you know, do some sort of a additional tooling.

B

On top of your cluster, uh we have also seen certain use cases where you you need to manipulate the traffic in your kubernetes cluster, in a way that you only want to allow traffic uh ingressing or regressing certain name spaces through some firewall gateways or security gateways that exist in your community in your cluster. Now. The intention here is not to do manipulation of that traffic. You know, because that is kind of outside the scope of a of a network policy. uh This this.

B

uh The intention here is that a cluster image should have the primitives or should have the ability to express these kind of traffic enforcement.

B

So if there exists a security gateway or a way to manipulate traffic, there should exist some ways in the network policy apis or the security apis to allow that sort of manipulation- and we also may want to you, know certain clusters, may let's say, have you know, fall under an attack or you want to deny certain uh pods or acts or certain services being accessed by outside ips, which are trying to do a denial of service on on the services.

B

So uh temporarily, you may want to enforce a a a rule that denies this particular traffic, so so that you can, you know, reevaluate your cluster and and take necessary precautions. So so you need a way to explicitly deny certain traffic either egressing or ingressing to your services or your parts. So these are some of the use cases um that that we collected over time- and you know, if you guys have any question- uh feel free to uh unmute yourself and ask.

B

I will move forward now having those use cases in mind and the motivation for a new resource uh when we started out writing the spec for a clusteroscope policy.

B

These were certain guiding principles that we kind of tried to adhere to and those those were the design goals that we uh wanted to achieve at the end of this proposal. um So so our our guiding principle was that we need to focus on the needs of a cluster administrator and not the app developer. uh That doesn't mean that the app developers requests are features uh that that are necessary for a developer uh are ignored. uh We, you know this.

B

This particular group, the network policy subgroup, does look at all those use cases, and uh you know anything that is developer focused. We can try to evolve the existing kubernetes network policy resource for for those use cases, but for for the cluster scope policies, we are going to focus on the needs of an administrator.

B

um We also want to ensure that we follow the network policy api as much as possible to to to give a familiar experience to users. You know anyone, who's who's, used, network policy, apis or written policies should not have a tough time. Writing cluster scope policies. The transitions should be should be smooth, and you know, of course you know as an administrator focus policies. The cluster scope policy is going to be slightly more complex than the kubernetes network policy, but our idea was to keep it.

B

uh You know as closely matched to the network policy api so that the learning curve is not much. uh We also wanted to limit the uh the amount of complexity.

B

That is that the api can, uh you know, because you know, as as the administrator focused use cases, can get complex uh a lot more requirements can come through for for this particular resource uh it is, uh it can get complex quite uh quite early, so we wanted to simplify some of that. So you know there were multiple proposals that we could have gone forward with uh and, of course, this they also remain as alternate proposals, uh because you know, as part of the uh coming up with a proposal for cluster scope policy.

B

We looked at prior art which exists today. uh You know, for example, we you know some of the network providers already have uh crds. For you know, cluster cluster scope policies, for example- uh mainly I think calicos, selium and andrea- has has a global or cluster scope policies that is available.

B

So there is some prior art, um so we looked at all the three specs and one one of the things that we we tried to avoid was the the ability to assign priorities to policies, because it may make make writing policies a little bit more tedious. You know, because you now need to remember or rely on the ordering of policies, so we try to keep it a little simpler and you know not make that complex.

B

But, of course, if, if we deem that now, our current proposal does not satisfy all the use cases or you know if, if if we think that the ordering base or priority base proposal, makes more sense and is more, uh you know more perfect for this perfect fit for this particular resource. We can always uh go back to the drawing board and and and work up a solution based on that, but hopefully we can find that this proposal solves all use cases and we can move forward in this fashion.

B

We also wanted to ensure that the the apis that we introduce is expandable in future. um We want to make sure that if there are new fields to be added uh to a clusterscope policy, uh it should not, uh you know, be difficult or it should not really warrant a v2 or a v3. Perhaps it should be additive to the existing uh proposal, so so so those are some of the principles that we wanted to stick to, and hopefully we can.

B

You know as we grow this proposal, we are able to stick to those principles so, based on that.

D

One question on the yeah on the principles: uh are we going into the kind of like designing the api? Are we gonna have a stance on how lenient or how aggressive we're gonna be around compatibility? um So, like is the first iteration gonna be uh well. I I guess like we have to start alpha, but like are we gonna go? Are we gonna create the apis alpha, knowing that we're gonna probably break something or are we gonna be alpha, but still be pretty conservative around um breaking users uh going into beta.

B

So I think the idea would be that before we go to beta, we have have a have a good amount of use cases satisfied. You know I'll talk about some goals and non-goals and- and I think that would be a good point to talk about like how the versioning might be able to be. We can we can do that, um but but the idea is that once we go ga it might, you know it will just be quite similar to how kubernetes network policies are.

B

You know once we want to add, uh let's say the name space by name. uh We had. We had that issue over here that you know we are introducing a new field. It changes the semantics, so we will try to conserve as much as possible, but you know there are no guarantees that you know future use cases that may come up. We might be able to solve uh uh today itself, uh but uh but at least I feel that you know we should have like.

B

Maybe a couple of inter iterations of you know, alpha v1 and alpha v2 before we go into beta and hopefully the beta is more uh stable.

C

Right uh abhishek, this is when I just to at your point right. I think you you make a very valid part. I think I just out of curiosity. I think our definition of a alpha api means we I mean we hopefully try not to break it too much, but at least that allows us to break right. I think once we go into beta, I think, is when we want to keep the api more stable.

C

That's my understanding actually so feel free to chime in like. If that is not the understanding of everyone else,.

D

Yeah, I think that's the general understanding and or at least it's the rule, um but, like you know, we we we can still. We can still make statements or still try to say, like people have built alpha apis, um but they treat them like beta apis because they know that they want early adopters and they don't want to break those adapters. So just kind of staying out like saying uh from the start like this is an alpha api, we're going to break it versus this is an alpha api.

D

Please use the alpha api and we're going to try our best not to make it like. I think it's good to set that um yeah.

C

And I think I agree with what abhishek was saying. I think we should use actually the first couple iterations of v1 to the alpha version. To see uh I mean what feedback we're getting in the field and then based on that, if we decide not to break it great, if we decide to break it, you know, unfortunately we will have to okay. So we are on an agreement.

D

Yeah that makes.

E

Sense, yeah yeah to at that point I feel like uh um it would be a good thing if we can sort of like get get some big c and hypervisors to be on board with this plan when we um are trying to. You know, do alpha for this.

E

um So if we have uh sort of some some sort of like consensus on you know, this should solve a lot of use cases and the cni providers are generally think it's implementable and it's a it's a the specs and everything makes sense, and I think we should be in a pretty good shape when we do alpha.

E

That's my opinion on.

B

E

B

Agree with what young said, we, I think, definitely need the support of cni providers, because you know at the end of the day, a resource. A network policy related resource like cluster policy without any implementation, is probably not going to be used at all. So it is definitely very important for us to have at least the top uh cni providers pack, this proposal, so hopefully, once we, you know, move this proposal to the sig network, um and you know once we are ready to uh publish the alpha apis.

B

We have enough backing from the providers and that's probably something that maybe we can take up during the sig network meeting.

B

Okay, so if there are no more questions, I'll move forward, so yeah as so those are the guiding principles we also uh so, as part of that, you know we kind of ended up with certain design goals uh for this particular proposal, uh which is, uh I think, we need uh a explicit deny rules uh which is unlikely in the kubernetes network policy. We don't have a have such action, they're all whitelist rules, so we do. We do need a new action for dinner.

B

We want to provide baseline security. The cluster administrator should be able to uh define uh some sort of a defaulting rules or baseline rules for its cluster. uh You know at least some guarantees for the kubernetes cluster, but they can be overridden by the developers, so we should leave the baseline rules can be. You know, overwritten by uh developers using kubernetes network policy.

B

A very good example of this is the namespace isolation, where you know, as as as a baseline, whenever a new name space comes in the intra name, space traffic is allowed and the inter name space traffic is denied and that's a guarantee that we give, and perhaps there is a tenant who owns more than one namespace and he or she may want to open up traffic between their namespaces, so they should be allowed to do that. So that's that's one of the goal.

B

The other goal is that a cluster administrator perhaps does not want their developers to override some of those rules. So in this case the admin wants strict enforcement of those security policies and kubernetes network policies should not be able to uh override those those rules. So those you know they seem very conflicting um goals, but uh I think we can demonstrate that we should we shall be able to overcome or we should be able to address both of these use cases.

B

The other goal is that the the administrator should be able to select pods on the entire cluster. So essentially, this goes back to the scope of the policy resource, which is you know, on a cluster level, as opposed to the name space level.

B

And finally, we also want to ensure that there is compatibility with the existing capabilities network policy. What we mean by uh this statement is that we do not intend to change any uh any um inherent qualities of kubernetes network policy. We don't plan to override its behavior, or rather we don't plan to change its behavior or the expectation.

B

Of course, when you have security policies defined at multiple layers like at a cluster policy and a network policy, the overall effect on the cluster will be different, but that doesn't mean that we are changing the meaning of writing certain communities network policies. So so the idea is that both cluster scope, policy and community centric policy coexist.

B

They are complement to each other, and you know the usage is, you know, one is for the administrator, the other is for developers, so those were some of the goals that we thought that we should achieve, at least as part of this first proposal.

B

uh Some of the non-goals also worth mentioning now, when I say non-goals, I don't really mean, or we don't really mean that these goals are not for the cluster scope policy.

B

These are something that can be addressed as part of the first iteration is just that: it's not the goal of today's proposal, because in our initial proposal, what we wanted to tackle was the uh we wanted to tackle the precedence and the complementary behavior between network policy and cluster scope policies. uh We wanted to uh tackle the goals that we just previously mentioned, uh but there are other use. Cases like you know, for example the node policies.

B

uh You know that's something that is also applicable for the crystal cluster scope policies, but it can be debated that it can also be applicable to kubernetes network policy. So the idea is that we can have separate discussions for such such use cases and see whether they can be solved for both uh the resources and if, yes, then we inherit it from that proposal. uh If not, then we'll certainly try to tackle it.

B

As part of the uh you know, the the original proposal here before we go alpha or even beta, so that uh you know we are, we are resolving majority of use cases that lie out there. So, but at least for today's session, uh we don't plan to introduce these use cases, which is you know, logging.

B

I know it is very some of the use cases. Some of the requests that were made on kubernetes issues were around audit logging. For you know, traffic that occurs in a cluster. It's an it's a useful uh feature. uh Perhaps we can follow up on this error. Reporting is something also that is, you know, quite arsenal, because you know sometimes users do not understand whether a policy was realized successfully or not, and I think the same this this this. This point is valid for both the kubernetes network policy and the cluster scope policy.

B

So I believe, uh danmanship is, has has a kept uh some around this for the network policy resource as a part of a status sub resource, and if that's something that uh you know is is moving forward, then I think we can also implement the same for the cluster scope policy using a status of resource, but at least we won't discuss that today, the node policies- you know this is something that comes up often, you know we want to.

B

There are two things: one is we want to apply policies on nodes and the other is we want to have the ability to uh you know, dictate traffic between pause and nodes, so on one hand, the the applying policies on nodes here, on the other end, the applying policies on pods as workloads.

B

So again, that's a non goal for today's discussion, but it is something uh that is also. uh You know interesting for cluster score policy.

B

We will also not talk about uh uh you know new selectors, uh for example, service, selector or service account, selector or dns policy, because already, I think in some members from the from this group are, are exploring these these policy targets separately.

B

So maybe we can keep those discussions in those threads uh so and then we can again inherit them and again, uh in the end, we don't want to solve a placement volume policy for every possible permutation. I think what we want to convey here is that there are multiple ways to uh you know: do cluster scope, policies, for example, uh you can also do h hierarchical uh policies like tiered way of policy doing uh policy enforcement. uh That's not the goal uh here today.

B

It is certainly something that might be useful because some network providers already do implement and provide that solution. But if, if it is necessary, then maybe we can take a look, but at least in today's proposal it's not part of the scope. It's not in the scope any deal breaker here or this sounds good.

D

I wanted to touch on one thing in the last slide. I think that I think the non-goals are pretty good um for the goals. I think um trying to keep parallels with the current network policy.

D

Api is actually is a really good starting point, but I do think that like if we get to a point where there is a much better way to express an api that would not be kind of uh similar to network policy, um I don't think it should be kind of off the table because it's too different from their policy api that I think we should explore kind of things that may look different if it, if it's a much better way of expressing um intent.

C

So, andrew, that's that's a that's a good point I think like this is like by the way again from google. So one of the things that we felt it may be more useful.

C

We didn't both the deny and allow context it gets like very complicated right so having and people are used to using a certain semantics like in terms of selectors and ingress and egress.

C

So if you use the same um language or the grammar, I think it will be a lot easier for people to comprehend, because with now with the cluster network policy, for for better or worse, it has gotten a little bit more complex with in terms of like you know, with the the prioritization of the cluster network policy or network policy and default allow or the baseline allow. So all these things get so this this would be useful. So now what you're suggesting, if I'm?

C

If I heard you correctly you're saying if we feel that there is a better way of representing cluster network policy and if it breaks with the way we have network policy defined the api let's go for it is. That is that. Am I reading you correctly.

D

uh I I'm just saying like uh like I, I think we should always start with what's familiar like. I think that makes sense yeah. I guess all I'm saying is like we shouldn't put something off the table because it's too different from existing apis. Like all I'm saying is, like you know, we should. We should consider different ways of expressing things, even if they seem different at first yeah, but I definitely agree with starting and meaning towards apis. That are, you know, familiar with to users and already existing for sure yeah. I think.

A

Probably the point here is also that we we have like here the opportunity to change what we think that's bad into the old api right. So we can. We can use this moment to like implementing the clusterscopic network policy that oh, we are not going to deal with with priorities, because we don't have them in kubernetes network policy and nice. I also think that we shouldn't like remove this from from the table, just because that's not compliant with the kubernetes network policy.

D

Yeah, I agree, I think it's a good time, there's a lot of confusing parts like for people just hopping into network policy. um I think there's ways we can improve it and this could kind of be a road map to do that. um So we definitely shouldn't restrict ourselves just because it's already defined one way.

C

So hey uh abhishek, I had like one more point I wanted to make. So if I heard what ricardo said and what I understood so um he's, I just want to get a clarification. Are we saying that, coming up with the breaking change for a network policy, a new version of the network policy which takes into account the prioritization deny allow the cluster level at the network level?

C

Is that something you should put on the.

A

Table, I don't think we should break how how the network policy works, but I think that we we don't need to stick with the like, follow the network policy api as much as possible for a farm for a familiar experience. I don't think we should remove anything from the table because that's not like the experience from the network policy api.

A

I I I guess that, like if the the decision of breaking something like backwards, comparability from from clusteredness clusters, copper network policy with the kubernetes network policies from the cni's, because here we are just proposing the api itself right. We are just proposing.

B

A

We are not proposing how they are going to work with that so who, who is going to decide? What's what's the backward comparability between them? Is it's the it's the cni providers?

A

But I think that that yeah andrew andrews say that breaking is the wrong word here, because we are, we are seeing about yeah new research so because this is a new research that that's the same approach from from the the ingress object when, when they decided to draw the new ingress, the ingress v2 that they called and later they called as a service api, they saw that the the previous experience from the ingress object wasn't what they were looking for into the the the proposal for the service api.

A

So I think that what what andre was saying here and what what what what I agree with that, it's that we we don't need to stick with the follow the network policy as much as possible, because we have like here the opportunity to change how it works and and and figure out what what the cluster I mean. They expect from the network policy and add as much as feature as possible without sticking with the old network policy, and maybe later we can like discuss if network policy. Api also needs some sort of syntax evolution.

A

As the network bonus api as the closer scoping policy.

D

But but I do think that, like what's already what abhishek already mentioned is like a good starting point, so I don't think we need to change anything right now. I'm just saying you know like before we go to beta if we find that there's a way to collapse like 10 fields into one field and like we want to do that, like we shouldn't not do that, because only if the only reason is like this is too different from network policy. We're not going to do it.

D

I don't think you know we should we shouldn't put it off the table just because of that reason, but as a starting point, this seems fine, so ignore what I said pretty much.

B

Oh, no, I think it's pretty. uh I think we should probably word it differently in the sense that it's nice to have this design goal. uh But, of course, if, uh like I think in previously, when I mentioned that when we looked at prior art like calico, andrea and psyllium uh for their policies, uh they are slightly different than the kubernetes. That.

C

B

Policy, because you know they have the ordering effect and priority based so, but if we do feel that you know that's the right way of expressing uh these uh these intents, then I think we should go for it. uh It's just that.

B

You know if, if that's a broad agreement in the community for that, uh but but I think to as a starting point, uh I think it makes more sense to start something simple and which is more familiar, uh and but I think one thing that we should definitely not try to do is that we should not break the kubernetes network policies, uh meaning today, for example, you know the cluster native policy is not uh not being written to um replace the community network policy. It's it's meant to be a complimentary to it.

B

So so, at least that you know we should maintain, maintain that. So I hope I was able to correctly summarize the discussion here.

C

No, I think, you're right. I think, but this is what we discussed here right, like I think, for the cluster network policy, we'll keep it as a separate resource, because I think sufficiently it's the the the elements of the cluster network policy are sufficiently different, that it begs its own crd uh compared to like you, know, uh merging it with the network policy without, like you know, um creating an entirely new.

B

Yeah and two to two, uh I think, andrew's strikers brought up that point, that certain things are confusing in the kubernetes network policy and we have tried not to reuse that, for example, the kubernetes network policy has policy types as a field.

B

We are not going to reuse the same field in in the telescope policy, because you know that that field was introduced uh for historical reasons, because the egress came after ingress.

B

We are not going to do that because we we can derive the same thing uh using the ingress rules or egress rules that are being defined so so we are trying to um in our proposal. You will see that shortly that you know we have tried to not use some of those confusing factors, uh but uh but also try to have a similar experience. So so it's not like we are adding. uh You know new selectors or anything they're still working with the pod selector or namespace selector, which are label selectors.

B

So so that's that's the familiar familiarity and I'm talking about.

D

Yeah makes sense.

B

All right, okay, so I think we went over this and then some of the non-goals so uh yeah so before without further I mean uh you know we can move into the proposal aspect. So first, I wanted to talk about. uh You know more on the technical side, like you know how the api types looks like. I think. Probably this is a good way to understand uh the some of the fields, and then we will look at um the uh like a sample yaml resource for cluster network policy with all the fields that we can.

B

We we propose and then I will hand it over to young to talk about a couple of specific uh fields that are new here and which has a certain different meaning because they're at cluster scope and the way we want to solve the problems so he'll he'll walk you through examples and diagrams and uh sample jamuns, so that that it's much more clearer, so I'll just uh first start with the proposal.

B

So as we said that we plan to introduce a new uh resource in kubernetes network policy, uh sorry in in networking apis, which is a cluster network policy, uh and before before I go through the rest of the fields, I just want to kind of lay it out there that you know naming is one of the most hardest thing to achieve and we are not stuck with any of these field names or the value names.

B

It's something that we appreciate more feedback on, so uh you know feel free to drop in suggestions for certain fields which, if you think that you know this name, does not convey the meaning of that field. So because we are flexible on those terms, so we would love to have more uh feedback.

B

So, having said that, um so this is the new cluster network policy resource. You know similar to uh similar to the kubernetes network policy. It has a spec which is a crystal network policy spec.

B

We could also do a status. uh You know if danmanship's proposal gets, you know more clarity and people are accepting of that, and we can also do the same thing for cluster network policy.

B

uh So a cluster network policy spec now this is where we will see some of the similarities with kubernetes network policy that we plan to do something similar, wherein your ingress rules and egress rules can be defined in in you know, with their ingress and eagerness field so again, similar to community network policy.

B

uh Now the the one difference here that you will see is that if you look at a kubernetes network policy spec, it has a pod selector here at the spec level in in our case. um In our case, uh we we decided to you know rename that field to something like an applied to.

B

What essentially, it means is that this policy spec is applied to these set of resources.

B

uh The reason why we need an applied to here is instead of just a power selector is, is because uh we need to um uh apply policies not just to pods but also name spaces, so so so for for us to make it easier to for people to write such policies and we plan to add a new field called applied to and and essentially it will be, a port selector or a namespace selector.

B

Now, if we look at the ingress rule or an egress rule structure there again, you will see a little bit of similarity that you have a ports uh field uh where you you we talk about that this particular rule is, should be matched against uh the sports and protocol, and uh you know we also, you know, get the port range uh for free, because it will be by then implemented in the network policy port. So so we should be able to specify a port or portrait and then uh similar to the kubernetes network policy.

B

It also has a from section and a two section from for the ingress rules and two for the egress rules. This essentially tells you that these per set of uh applied two parts can either talk to uh these set of uh pods or can accept traffic from these. So the semantics is very similar to the kubernetes network policy. So no change so far.

B

The new field that you see here is an action you know, which is of type something called rule action. uh The action field is uh is pretty important, is one for you know for one that it is not available in the kubernetes network policy, because you know all kubernetes network policy rules are whitelist tools only, but we do want to have the ability to deny a certain traffic. So that's why we introduced this new field action, not only that the action also determines the precedence of the rule as compared to a kubernetes network policies.

B

So so we will deep dive into them with examples a little later, but uh on an on a high level, there are three type of actions that are available: uh the rule action. uh Now the allow action is an as-is rule. What I mean by an azure's rule is that it does not have any uh implicit behavior.

B

For example, let's revisit what a kubernetes network policy does when a kubernetes network policy selects certain pause in part selector and has certain whitelist rules. If the pod is selected by that part selector, then the traffic is allowed only by those whitelist rules that are available to ingress and egress.

B

Otherwise those pods get isolated. So that's the behavior of the existing humanity network policy.

B

On the other hand, an allow rule is, as is that is you know there is no implicit default isolation of those pods, the the traffic that is matched for this rule will be allowed, and if, if it doesn't match, then it falls through to the next set of rules.

B

um The other thing that uh then, is also worth to note is that an allow action uh will always uh precede any kubernetes network policy rules. So basically the allow action will be evaluated first and it is basically think of it like if you have multiple cluster network policies, you you know, each of those cluster policies may have one or more allow actions.

B

They're all kind of you know aggregated, and you know if the traffic does not match any of those allowed rules, then it kind of falls to you know how the traffic is uh allowed or disallowed based on the community's network policy rules.

B

So so the allow takes allow takes precedence over humanities network policy um and, since you cannot have conflicts between, you know, multiple allow rules, they're all addictive they're, all uh they're, just like kubernetes network policy, they're kind of whitelist.

B

The next action that we see is a deny action similar to the allow rule deny action is also as as this rule, that is, there is no implicit.

B

Isolation or you know the opposite of isolation that occurs for a deny rule, so the rule will be evaluated as is again similar to allow you know all deny rules. Multiple deny rules cannot conflict with each other, so so they are also additive and, uh and they similar to the allowed rules, will also precede uh the cluster, the kubernetes network policies, so the deny rules will be evaluated first and then all the capabilities network policy rules if the traffic did not match any of the deny rules.

B

Now you may say that you know there can be a conflict between an allow rule and a denial and that that is certainly possible. You may have the same selector, you may have the same port and you may have the same to and from uh for for multiple rules, and one of the action is says, allow the other says tonight. Now that's a conflicting.

B

Those are conflicting rules. In that case we say that deny always deny always wins so now, if we think about the priority the precedence we have, the deny the aggregated deny rules at the top. The aggregated allow rules after that and then once all of that is uh evaluated and no traffic is matching, then we go to the kubernetes network policies and then we see how the kubernetes network policies. uh You know the semantics remains the same.

B

So so that's the current proceeding and then the third action that we introduced is a baseline, allow, a baseline allow is evaluated after all, the communities network policies are evaluated.

B

So essentially, this lies at the bottom of the of the precedence uh priority so and the other difference is, uh or rather other similarity with the kubernetes network policy or for a baseline, allow rule is that it is similar to a kubernetes network policy. uh Allow rule uh in that that any applied to uh is selected and has a baseline allow in its rule it it it will be only allowed if there exists a baseline, allow rule. If not, then those workloads get isolated.

B

So uh so this we will look at further examples in the follow-up slides and I think you'll get more clarity on this any questions. I know this is a little bit of a mouthful, so it can get complex, but hopefully the following slides make it more.

C

Andrew was commenting in the chat that you wanted to go from baseline a lot to default a lot. Maybe you want to give a little quick summary of the discussion that he had in the meetings.

B

D

I know there's there's only eight minutes left, so you know if there's context, I can catch up on it later. I don't want to. I don't want to spend time on, on the other, slides.

B

Yeah, just just a quick uh response to that is that we started off with the default allow and I think, uh just last week we changed it to baseline, but we can. We can talk about it in follow-ups, okay, yeah yeah, and so this is how the the rules are or the api types for the scope resource cluster for resource. But this is how a sample cluster network policy resource may look like any yaml form.

B

You know. Essentially, you know this. You will see that there is no name space here, so the name is a sample clustering policy and it applies to a namespace selector, which is empty, which essentially is similar to how kubernetes semantics is for the namespace selector. An empty name. Selector selects everything. So here this will be applied to all the namespaces that come up in the cluster. So as a sample here you will see we have dmz cube system, these few name spaces that exist. The policy applies to all of them.

B

It has a three egress rules and one ingress rule. The first egress rule denies this namespace to talk to everyone except the istio egress aerocube system. So every namespace can only talk to the istio egress or the cube system namespace. Otherwise they do not talk to anyone.

B

It is also allowed to talk to this particular site, so maybe there's an internal sider that cluster he needs to be able to talk to. So it explicitly allows traffic to this uh cycle for all the namespaces and it it is allowing as a baseline rule. That is, you know if there is no network policy overriding this, it is allowing uh these name spaces to talk to the the core dns pods or the uh coding spot that exists in the cube system namespace.

B

So essentially, this is how the egress policies for every namespace is applied, so the udp 53 is for the score dns pods. So so that's what this particular egress rules uh dictate the ingress for these.

B

These namespaces is only allowing it from uh dmz namespace and and denies it from every other namespace, so it can only receive traffic from uh this dmz namespace, so it's kind of allowing this kind of a workflow here.

B

So this is the sample cluster network policy resource and I think, uh like I mentioned, I think this is going to span multiple sessions. uh Probably this is a good stopping point. I know um you know. I know I'm sure that there are a lot of questions that may come up and you know as you as we go move forward. You will see a lot of examples that we have uh here for every.

B

uh You know these confusing aspects that we proposed, uh but maybe you know we can talk about it uh next time we meet because I think there's a lot of content left for just five minutes.

B

So maybe we stop here and then uh you know if anyone has any question feedback so far we spend the next five minutes discussing that.

D

So one quick clarifying question on on the last slide there, so there's a deny rule for all namespaces, except for istio, egress and food system. So if a pot did want to egress out to those name spaces, is it implied that there's an allow rule in the namespace network policy in that namespace or it doesn't.

B

D

Of the yeah good sorry.

B

D

Ask that question again: yeah! So there's a there's, the there's a deny rule. The first egress two is a deny for all namespaces, except for sdo egress and cube system right so yeah. So if I, if a pod didn't want to, if I wanted to allow a pod to egress traffic to those namespaces, um is it assumed that I have a namespace network policy that allows it.

B

No, no, that's not necessary, because you know- and here what it says like I said, the deny and the allowables are, as is so. It's just saying that uh we do not have a deny rule for is to egress or acute system. uh Now, if you want to deny that, then maybe you need to write a new policy or something uh or a kubernetes network policy to deny that explicitly.

B

If not, then it just water falls through and it will see whether any kubernetes network policy denies or disallows this kind of a traffic. If not, then it kind of flows through the baseline allow rules. If not, then eventually it allows the traffic. So so you don't need to create a kubernetes network policy to allow that is this. This cluster network policy does not explicitly deny that.

D

I see okay, so if you exclude it from a deny rule, it falls back to the default, which is allowed, if not selected by anything else.

A

Check, I was just wondering: how would you allow traffic deny a traffic only to a specific id? This is the same like you, you put an action. You you change that as an action to deny is that yeah? Okay? So it's okay.

B

Then you would change this to deny and you know all deny rules are additive, because you know you won't have those conflicts and you always have the denials too without so you could do that and you could also do a deny for an ip block cider with an accept which essentially would mean that you don't have a deny rule for that. Accept block it's just that this policy does not create any rules, special rules for that except law, so similar semantics as what we have for kubernetes.

B

Also, you could do the same for for allah with the accept block.

C

C

I think abhishek, I think you may want to point out that it was never the intention that it was you're going to conclude this proposal in like one session. This is going to be like a and a lot of people are out this week like at least from folks that I know so. Maybe I think what we should do is like slide that shake and yang put together. I think it's we get an opportunity to go through that and then in the next meeting, whenever we have a start, we go through.

C

The people will have more time to digest it, and then we can have more robust discussion.

A

Yes, this this, this section is also recorded. So I was like like expecting this to get into youtube channel and maybe do some some some marketing about that. So people can take a look into the first. Take a first look into the proposal.

B

Yeah that yeah that'd be great, and I think you know there are a lot of uh examples. We.

C

B

In the follow-up uh with with like a step-by-step slide on how multiple customer policies interact with each other and how the semantics are for the the different actions that we have and also how a pod selector semantics differ in a cluster scope policy versus a kubernetes network policy, I think those are important fundamentals to understand and you know the rest of the slides.

B

I think we have good content to cover those aspects, so I don't know when we will meet next, but perhaps it's some. I expect that it'll be sometime in jan, so maybe maybe for the next meeting. We go back through this recording and uh and come back with. You know questions because I'm sure there's going to be a lot of digesting to be.

A

Done sounds great.

A

Thank you all. Congratulations! Folks! Congratulations! That's! uh That's amazing!.

C

Yeah, I just want to say thanks great job appreciating.

D

Yeah, that was great. Thank you. Okay, thanks. Everyone.

A

So for the next week, do you think it's worth to us to have this meeting I've seen some other six cancelling the meeting? That's uh I'm! Okay, with like.

C

I don't mind attending ricardo, because this is pandemic. We have pretty strict lockdown, so I don't haven't, got any plans so we're all gonna be stuck at home, so I might as well join in. But having said that, it doesn't mean others don't have plans. So if you're going to have it- and you can count me- we can, we can.

A

We can we can start discussing. I saw your proposal about this service selector, so we can use the next meeting to just discuss yeah. We can maybe like okay, that's a good point, because I don't think we are going to have like enough people to discuss about the cluster scope network policy. So we can. We can leave those two or three weeks for people to take a look into the video recordings also and this live deck and so on. So we can start discussing about about that services. Selector sounds good.

A

All right see you guys yeah! Okay! Thank you folks, yeah! Now the fox congratulations! It was great job. Yeah see you folks, goodbye.

D

Happy holidays, everyone happy.

A

Happy holidays.

A