Istio Ambient Mesh Working Group Meetings, 14 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ambient Mesh WG Meeting 2022 12 14

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

I mean all right. Thank you. um So yeah welcome everyone so I. uh First, the announcement is I. Don't believe we have a meeting next week so we'll put on the agenda.

A

um There would not be any meeting next week unless John, you tell me otherwise.

B

Okay, sometime.

A

Okay, yeah I'll, put on the meeting minutes um and I think uh we only have one agenda on the um um the.

C

Meeting we have meeting the week after on the 28th. Are we doing one probably.

A

Now, who is going to be here.

C

I'm, just gonna assume no yeah.

A

I'll put in the notes, uh so we don't have any meetings. Yeah um next up, you'll see I'd like to you to take over the discussion of sea tunnel layer for policy designs. I know: there's a little bit of disagreement, so you'll see go ahead.

D

Yeah, it's Coast.

E

D

Yeah, okay, so I kind of summarized the open issues of the open concerns that we have over the IDS and the the message that is defined in this design document. The message itself is I mean the Photobucket kind of a living live in photographer, I'm, updating the photographing, based on the uh feedback that I get from from the people over here. I I know that I still need to Target. They mean concern about the logic of all and end, and so it would probably be updated further.

D

But there is a bigger or much more deeper question question which costing rises in in his comments and what is, and if I understand it correctly, it's whether or first whether we we why we are not using the.

D

In order to pass the information between the control, plane and the tunnel, and if I read behind between the lines of questions comments it, there is also a hidden question whether we actually want the custom you can collect. If I want, uh whether we can we, we actually need the next in a new external API. For that, so we can use one of the existing.

D

The existing names API that will allow us to filter basically do some basic filtering on the resources that we want, but we will get. We can present camera. Okay. That time you can get the Institute of Education authorization policy. Resources from from the controller am.

F

I correct question: yeah you're, absolutely correct, I mean even today you can get the resources from from D tunnel to istio D with the existing protocol. I'm not saying we should not change the syntax of the I mean we can change the actual URLs that we use to to retrieve it to be something different and put the filter. So it's Network compatible, but even with existence you ID with no changes whatsoever. It is implementable already, so you can. You can ask for giving all the policies rust can very easily.

F

You know, process existing is your resistant I, don't know if, if you can show how the different Proto will be easier to implement in Rust, I would agree with a different Proto, but I don't really see how, if you move the fields a bit around, you make it easier to implement the harass you still iterate you'll still create some internal Maps you'll. Still. If, if you, if we find some Rust implementation of that, it's in Broad uses tested and we convert from hour to whatever rust already provides.

F

If it exists, then yeah, then then it's easy because we can just reuse the crate and lose the translation mystery I can I can give you that I.

D

Just don't come and record before I pass it on to John and lemon um I. Don't think that the consideration overly was to whether it's simpler to implement the cost or not I mean it's more about the.

D

What is what's the data and how? How can we scale the information better when we use this type of schema new schema that we can aggregate the policies and I I? Don't think that we ever considered or thought about whether it's click simpler to implement, invest.

F

Yeah, it is just different, then, what's the point I mean we are just inventing a new API. That is doing pretty much the same thing with different words and we don't really gain anything. We just delay the process because we need to implement it in security. We need to implement it in Rust. We need to keep it stable and it's not going to be stable because, probably iterates since it's a new API versus something that is stable, Works can be used today with no change in history or D. Maybe some optimizations later.

B

Is that if we do that, we need to not just modify the auth Z I mean what you do is unmodified like you're saying, but we'd have to modify the workloads to send all the labels and that would basically double the size of workload. Proto.

F

Why would they need to.

B

Well, lots of the policy have a label selector. So if you're sending the RC policy, as is then, how would you implement that if you don't have the workload labels.

F

Oh, but I saw that we do send labels in workloads. No, we don't think that yeah last.

A

Time we discussed uh this was a challenge because we don't send the label, so you have to redo the work to think out which policy of sleep policy is associated with which workload through the selector.

F

uh I I'm confused, uh so there are two kinds of labels: one is sending the labels of you know the not metadata like we sent today and I think we have those we don't have to send them into the I mean, and the other thing is a workload Proto where we return the labels for the destination. We.

B

Don't return the labels in the workload Proto.

F

B

Know I know I know, but but my.

F

Understanding is they're, not curious, they're, not Z policy I mean we use the labels to select where they match and that's not based on the remote or the peer labels, but for peer. We only use the information that is in in on The Wire.

B

uh uh So, okay, if I have a obviously policy that says, match app equals who now I think you're proposing we send that policy, as is directly to Z Tunnel right.

F

uh Yes, more or less so.

B

Now, when Z tunnel gets a request to the bar service, how does it know whether it should apply that Odyssey policy or not.

F

So uh but but they will not get, it will not get the labels from um I mean, isn't watching the post? Don't you get need to get some good information about all supports running on the Node anyway, foreign.

F

Information about yourself about Local.

D

A

F

How do you implement annotations about you know we, including reports? How do we Implement that's.

B

Not handled by the tunnel, that's handled by the cni.

F

Okay, so let me rephrase uh the combination of whatever runs on the Node, that I'm not proposing changes to the workload API, how to get labels and proposing that the Z tunnel should be aware of more information. And yes, if you want to filter it, I'm. Okay, with that as well I mean to have history. I did do some pre-filtering and- and uh you know, return a slightly different format, but not with changing the entire uh structure of the API. What is matched.

B

Okay, so you're saying we would basically for only the local pods, you get the labels, but not for all the parts. Yes.

F

Makes it scalable that's another option? uh What what do you prefer? The problem with pre-filtering an ISD I mean I still doing some label matching. Is that if history goes out for a while or we have any problems, then a new pod starts on on the Lord, and we may have a delay where, where the body is running, but we don't necessarily know the what the policies, because this study couldn't sell them.

B

But we won't know about the part if it. If history is not running so we would have to block.

F

uh We block for startup and at this Point's IP table annotations are known, so we know the labels all ready to to before we start but estrd may be delayed. So I don't think we block until it's your distance, all the authorization because it the studio, will say no I, don't know I didn't receive yet a notification on the phone I didn't match it. I I will not uh yeah.

B

So the Z tunnel has to get all the info about the pods on its node from Easter D, so he's just D is down, I won't get that info and then, when it gets a request, it was a this IP address. I, don't know who this is and it will project it.

B

B

Entity so it seems like you, can't, really have a outage velocity without an outage of workload as well.

F

Okay, I need to think about it, but uh going back to the point, um are you are you getting labels for the local workloads? Is it a problem with that? Do we think.

B

We don't do it now, we could do it. One concern that I have- and this is a much much broader concern is today we have the workload of resource and it is not client specific right, and so we could. We actually don't do this today, but in theory we could take that pre-generate all the serialized protobufs and store them in a map and then just pipe those down like a CDN right um and that could be in other implementations, even more like a CDN.

B

um If we make it so it's client aware, then we have to go regenerate it. Every time.

F

B

I mean there is an alternative like it's a different type or something like there are alternatives. Certainly I'm not saying it's a deal breaker, but it's just something. We should keep in mind anytime, we're making a client specific paying in workload. So.

F

Yeah, no I I think I think that we should I I agree with you uh workload and we we may need different variation of workload. uh Protocol I mean different names. Someone mentioned a question mark I mean a query, parameter or a different URL syntax about what we return um so I'm, trying to understand what what what is easier for for us I mean to have this mechanisms to return labels with an alternative to workload or workload with labels or some other protocol, or to do the label matching history as a general rule.

F

Is it the only case we have where we need to use labels? Then probably it's okay to go with matching labels in stud. Otherwise, maybe we should take the more General solution, because.

B

Yeah I think the other case we would need labels is when we add Network policy, but I think that if we do this, we should use the same Proto for obviously policy and network policy. So Z tunnel doesn't even need to care that they're the same for that. They are um different, user-facing ones because they ultimately are representing the same information.

G

Do we need the labels in places other than Aussie.

B

Yeah, we don't put the labels in Telemetry. Now we put a few a few labels. Specific labels become things in Telemetry like the version label, but that's already part of the workload Proto.

G

Okay, uh yeah, so label information will be set. It's just a. We may not use the label as the identifier for workloads inside the RC policy.

B

I wouldn't say: label info will be sent if it's more, like labels can configure some specific properties of the workload like version and version is sent, but that's not the same as saying labels are sent because we don't send all the labels. We send very specific ones and we're technically not sending the label we're sending something that can be configured by a label, but it can also be configured by other means.

B

That makes sense.

C

I think I I, don't necessarily know the answer either way on this, but just as a general principle, I think it's a good idea to keep Z tunnel as simple as possible and have as few kind of higher layer abstractions leak into the data plane as possible, particularly when you consider that, ultimately, we're going to expect alternative implementations we're going to expect cnis that build the tunnel-like functionality implementing the same API, the thinner. We can keep that and the more we can keep out of the data plane in terms of logic, I.

C

Think the better so I just wanted to kind of flag that.

B

Yeah, like one example where I think is kind of a irritating, is that these two API has like from Two and then which are typed and then when, which is just this arbitrary string thing that can match anything um and has like prefix and suffix matches and all this craziness.

B

um It certainly could be implemented in D tunnel. But it's kind of nice to not have to worry about that and just get kind of a sanitized uh version of it. That's kind.

F

Of minimal so uh John I, I I, don't disagree completely with you, I mean um if we have to implement a tour policy, but if we decide to Environmental Policy I, don't think we have too many choices except to send the labels, because that that involves source and destination labels and I, don't think there is any other way to to use it.

F

How about we kind of split the baby or, however, it's called Uh we Define a workload with labels, it's not very difficult to put in history and it doesn't have any cost in history, and we also Implement filtering on sdod, based on uh workloads and on the matter of protocol. If we Implement selection in sdod, obviously will be a small change in what the protocol we have today, but we can still reuse the rest of the protocol. So the when, where I mean all the structure of the protocol will be the same.

F

But we'll add this: you know kind of. Instead of sending the label selectors will send the label as a workload ID or whatever history is using using.

C

Can we add labels later if we need them like why? Why do that now.

F

Let's put them there, I mean it's, not it's a small change, and, and again it's not uh so.

H

We don't have the.

F

Discussion again, basically so we'll have ability to get labels if we need them debugging, Telemetry, whatever Network policy. If someone wants to implement or policies that will be the only way I think we agree that you know we don't have the same luxury with network policy where we just have five seems that we need version.

G

Yeah I think I agree with costly uh label will be very valuable in many places like Telemetry I'm, pretty sure we will need to send labels associated with the workloads.

A

B

Second, yeah: we've.

E

Already established.

G

E

B

Need a certain Fields per 20 implemented, so this is not theoretical. There are very specific attributes we need for Telemetry. Those are already sent, that's orthogonal from sending labels. So, let's not- let's not mix this up.

A

Yeah I'd like to see a conqueror scenario where we need labor before we can.

F

Add Metropolis right Metropolis.

A

Network policy, but if we translate so I think you want to add a label, because you want to send the RC policy from the control plane to.

F

The data plane no, no, no, no, no, no! uh So for a VM again on right now in kubernetes, let's say the cni layer is implementing Network policy and you can express allow from pods with labels X and deny from both the level. If we run zitana on a VM or outside kubernetes, we either lose Network policy. So if the VMS will not obey, not our policy or implementator policy in zitana to implement Network policies, Eternal will need to support arbitrary level because, unfortunately, Network policy is based on arbitrary labels and sourcing destination. Yeah.

A

But you can get the labor information for the co-located parts. Like you said right, we don't need to send that from the control plane.

F

uh For for Network policy, you need source and destination labels. Unfortunately, so you need to get both so.

A

Basically, the sources not Source doesn't located around the same node, but.

F

That's fine, it doesn't impact the protocol in client it'll be just a slightly different resources that returns same information plus labels. So normally we don't pay any cost, but if someone decides to implement Network or something that requires labels, whatever I mean Telemetry extra hour, then we have the ability to to get it relatively easily. I, don't think it's a bad sink anyway, it doesn't hurt anyone.

A

Yeah, but to eason's point, uh which I think a lot of people agree. We want to keep the tunnel as minimal as possible right, so it's almost feel we would add stuff when we know we absolutely need it.

F

No initially I don't think we need to keep this studio as simple as possible, because.

A

Yeah I mean yeah I'm.

F

Saying exposity, maybe it will not be implemented in, maybe maybe the network police will be implemented with some other mechanics. Who knows.

G

F

G

Have the workload API and in workload API in the workload definition, do we have the set of labels or or Jones? That is only specific levels, not including all the levels.

B

We do not have the labels, we okay.

A

And what costing is proposing is to add the labels, if I'm hearing correctly.

F

Right with labels, let's define a new protocols.

A

F

And history will support both if someone wants to know what labels them they get into tables. Okay,.

A

I see what you're saying so they could opt in to get without label if they don't care.

F

Without labels I mean, but if you need Network policy or need to implement some some policies that requires label, we have it there for, but that's a different discussion, I mean I. Think we agreed now that that history will do selection like original proposal. It's just a matter of uh how do we express the rest of the protocol? Basically.

A

Okay, I see a couple of hands: I want to make sure we get through them. uh Is that you.

A

Okay, maybe not uh Ethan, did you also had a hand yeah.

C

I'll just say: I, don't know whose decision this is, uh but stepping back to me. It really sounds like there's not an immediate use case for labels, I, I, I'd, say 70 by the argument that we'll need it when, if we Implement Network policy, um I want to get this thing out the door quickly, so removing features is better, um so I I would like.

C

We can always add them later so I I would propose that we file a bug on it, um put it in the backlog, but like say No Labels, at least in the alpha release.

C

um I guess my meta question is: how do we like make a? How do we arrive at a short-term resolution on this? Like? Is there maybe not, maybe not unanimous consensus, but is there a majority majority consensus on this Panther I.

F

Don't think we have any major disagreement, I mean I. Think most of us understand like we may need labels. We have a way to add labels and it's pretty simple. We don't have to do it now, and this problem is not blocked necessarily on the labels. I mean so only issues that we still have with this proposal is. If we uh do I mean it's it's clear: all the selection is your D, because we need to do it in UF optimization.

F

Do we send the protons that we have with the name of the workloads that match or or instead of the label, so basically just substitute overall selector with the concrete ID? Or do we redefine the entire thing.

C

So yeah say that last sentence one more time: it didn't quite crack it so.

F

Do we send the existing authorization policy as it is today defined, except replace the workload selector with a list of selected ports that each study will select? So history takes the labels? Does the matching and send to the tunnel hey?

F

If I have this policy to apply to Port one two, three four by IP by whatever identifier we can come I, don't know what how we can, but the rest Remains the Same I mean the rest of the Proto or we Define another representation of the Proto, which is you know closer to Something I Don't Know, like we do it with a voy.

C

G

Yeah I think for the work of the selection, uh I. Think most of us already arrived at Rough consensus right. We can uh as a cost interest rate, we can have the set of costs selected by ECT yeah um toward basically to replace the label, selection or label selector in control place, and the other thing we want to discuss is the Outback rules. How do we represent it? Do we want to I think there are two two options like uh that: I think is possible. We can move forward.

G

Why is directly copy the control plane portal just remove the L7 properties only sent to The L4 properties and the other possibility which I can see uh which I mentioned in one of the comments is. Maybe we can consider something similar to what is implemented in my Outback protocol today, everyone Outback I'm, not saying we should use everything in my iPad because the currently it has like principal permission and we don't need this distinguishing, but the part of that I like about nyr case. It has unlimited uh nested and then all combinations.

G

So you can, you can have any combinations of and then all of the properties and.

F

G

The end of the implementation is actually very pretty efficient. The code. If you look at the code, it's a it's very short but yeah. It's extremely flexible, I.

B

Mean I think what you listed as the pro is at con and doing more than we want, is just an attack surface place for bugs Etc and I. Don't agree that it's efficient in implementation, I mean I, sent you a link to the example of a simple policy that becomes for like 300 lines of code. It's doing regex's to do simple.

G

B

Don't need regexes, for example, like we can have a much much more optimized implementation by.

G

Being specific, yeah that's generated configure instead of the code, the code is actually very simple.

B

Right so I can basically ask you the coaching the generator config is what's sent over the wire, so any large amount. Any large Proto is extremely expensive.

G

That's that's what we need right. We we need at least the two levels of, and then all right.

B

G

Need to look at the policy so.

B

What, basically, my argument is that we should have the most efficient simplest form over the wire right. If that ends up looking like Envoy, that's fine, it's not going to be the same as Envoy I almost guarantee, but it's actually very simple. This is not subjective. We can quantitatively go and test out two protos and see how efficient they are right. It's a very simple single number output. So, if, if we want, we can go test out side by side and improve it, we don't need to you know kind of debate over it.

B

On the other hand, the actual implementation I am very confident that I can Implement something more efficient than a regex to do what we need to do.

G

Yeah I'm pretty sure we want to remove the parts like regimes or anything. We think that's unsafe and we don't. We don't support it anyway. In istio API, no.

B

But I feel like we're almost agreeing, because we were saying we want to take Envoy and strip out all the parts we need to get an efficient representation and that's exactly what I'm saying as well. I guess. So my only thing is that I don't care at all about sticking anywhere similar to Envoy if it's not the most efficient I, only care that we end up efficient, but if it looks like Envoy without the bad parts of it. That's perfectly fine with me. Okay,.

G

B

We're more agreement than just greens go ahead. Austin, oh.

F

Sorry Ethan is before sorry go ahead.

B

C

uh I, don't think my hand was up.

A

No, it was yeah.

E

No I was gonna say you said that the the one goal is that is the efficiency over the wire, um but you would also said that we want to keep the code in the Z tunnel as simple as possible, so the one goal cannot be.

B

All right you caught me in a lie: I meant.

E

E

All those feels to me it's secondary to the Simplicity of the implementation in the Z tunnel.

B

I think it's a balance of the Simplicity on the control plane on the data plane and over the wire.

E

Because if it's the efficiency over then envoys API makes sense. Because it's like.

C

Or whatever, like.

E

Then then it's a different goal, so I just want to make sure that yeah.

C

Quick, quick, quick interjection with the metapoint, often with projects like these. It's maybe not a bad idea to write down what the goals and non-goals are I think we could write down and agree on four or five of them, um so that.

F

C

A good thing to do out of fan.

F

Even if they are conflicting, yes, uh so uh one one one one point uh here is uh we we go down. You know it's a rabbit hole basically I mean we will keep discussing for many months. What is the most efficient wire versus whatever versus the same way?

F

What is bad enough way, how a general purpose language can be optimized, and then we have to because employees, basically an expression language that is evaluated and so forth, how about pragmatically just start with what we have in history API, because that's exactly what it's a minimum thing we need to support, so anything we have to. It will be extra.

F

That is, you know, effort and testing, and if later someone, you know six months from now, somewhere Heaven Wasn't representation or ebpf translation or whatever fancy language intermediary language they want to Define and they prove that it's more efficient than what we have we can go with it. We can swap it it's implementation detail, but to get started. I, don't think the current photos that we have in istio are difficult in Rust to to parse and create some data structures that work efficiently, because it's.

A

Yeah I would say the only challenging I have is so folks two weeks ago we will discuss this topic right and uh on that call everybody was kind of prefer. There needs to be some internal representation of um authorization policy for layer, four right, so that's the past yossi has been going through and I think you also have some prototype. That's working on his machine, so number one is folks already made. Some progress by yossi number two is form the requirement of the car two weeks ago. I think we made it clear.

A

Whatever internal representative we want to come up with, we need to cover not only the SEO uh RC policy, but also the network policy for potential down the road, which is why another argument point that we believe uh the internal representation is needed for a case, because the like istio ABAC couldn't cover the network policy.

F

Yeah, that's that's. Nothing is wrong here, I mean everything is still true. We do want at some point to have an internet representation that can represent whatever we may. We I think we don't disagree that eventually we need to implement our policy, but it will be a different proposal and you know maybe we'll send Network policy on the wire and but to get things moving and to not get bugged into discussion about what is the most efficient and future proof and can implement it or policy representation.

F

We could just you know, do the minimal things that is required to to get it supported. You know.

G

Yeah I think that's what policy can be the next goal. It's probably not the one we've tried to optimize in the first implementation. Natural policy actually includes what causing the source labels Source labels can be either can be used to identify the client, and it's probably not the goal we want to achieve in our first virgin and yeah I. Think one of the important goals in Sea tunnel. We should try to optimize for implementation efficiency.

G

That's why I was talking about the existing. My back like you can handle the embedded like any level of and then or combination very easily like using very short code. Otherwise you have to duplicate the larger click in several levels. If you need two levels, three levels, you basically duplicate the same logic every time you need to generate, and then all logic, so yeah, uh of course, I'm not saying I already yeah, like the previous discussion with John.

G

Another thing: we want to duplicate everything and why are back like we don't want the permissions, the principle different differentiation and we don't want to include the Radioactive uh yeah. We can only include the minimum sales.

G

Go ahead, yeah.

A

Go ahead and electric charming and you should be weighing on Simplicity from a coding perspective too.

A

You're muted you'll see.

D

I'm just saying that it's a great discussion and I'm actually leaning the world is suggestion of costing because.

D

Is suggestion is that we will use the account of the authorization policy as a vehicle or as the message to be passed on the on the wire, and we will clean up the uh illness and pass from there. I mean we will clean up the entire seven policy. We don't care about those, and we will also replace the selectos with something which turns the attorney cannot understand and all the logic that we need is already there I mean the end, the laws and whatever the user defines.

D

This is what the user defines. So we don't need to convert that into the the invoice, the presentation or something something that I defined in the design tokens right, I kind of like it I mean it's everybody else.

D

In favor of that.

F

As a First Step, At least I mean I I, don't think we are seeing or anyone saying that optimization cannot come later or you know, generated BPF was more whatever is not possible in the future, but let's ship something.

C

Can we turn this into a written proposal um and I think that would help um or I I'm I'm having trouble agreeing to something because I'm having trouble holding in my head? What we're agreeing to.

G

Yeah you'll see, maybe you can show us some that we can see yeah if the logic makes sense. My yeah, my biggest concern is: if your direction implements the control plane protocol. Will the implementation code become pretty complicated.

G

Yeah yeah, maybe uh you can just go through uh well, when you are ready, you can show us the examples. How do you plan to enforce this control plane rules directly? Let.

F

Me a quick question, a quick comment. uh His demo I mean his his implementation and dog. The format is about the same thing that we have I mean it's not yeah. It will not change too much. So it's it's really just different names and different protocol for pretty much the same thing right.

G

Yeah I actually recommended on the Outback policy rules in in USA stock I gave one example, I think uh yeah in of the policy of the current control plane policy I think it's a actually in the country proposal, there's only one level of nno, so it's not possible to implement some of the policy we already supported today.

D

But but if you take the policy as it is, so you don't need to convert it into the logic of the Outback message right, yeah.

G

But still you need to you need to have the logic implemented in the code for different for the multiple levels of nlr.

F

Yeah it'll, be it should be him.

G

Yeah yeah another yeah I. Another point I I made is because currently we we still we're still going to support sidecar, so we're going to have some logic to converge to the myr back, so the logic already exists today. Maybe we can have some shared Logic for both ambient and the second and the data plane. Implementation can also be yeah. Actually, the animal Outback implementation is pretty simple: that's what I can see, but yeah, but maybe yeah.

G

Maybe we can go through the concrete policy examples and the user can show us how the you know how the policy can be enforced using custom logic.

B

Women I was going through the photo and I was Disturbed to find that it sounds like we can do. Prefix and suffix matches on any field. That includes like namespace is that accurate.

G

We can do yeah, we can do some suffix in the prefix image any field, including namespace and the IP. Yes, is there a concern.

B

A concern on a suffix match on an IP address, I.

G

P we actually support a cidr IP blocks, so.

F

John, it is a V1 API. We promoted it to stable, I, don't think we can change it.

B

I, don't yeah I was just making sure that we implemented. If that's what it that's.

F

Right to implement it as much as possible, I mean, but but I mean with within ways that with doubles, I mean it's even more craziness that is coming with employee, because it's a far it's basically an expression language that you can be as complicated as far more complications that we have already so.

G

Yeah yeah yeah: we don't have to support the whole so avoid yeah functionality supported in and.

F

Why and why bother with it if I mean if it's exactly the same, what we have in history of policies and it's we implement.

H

F

Otherwise, if it's more than we already waste time on something more.

C

Okay, so taking a step back in this specific meeting, um what uh outcome are we driving to so I think there's a decision that needs to be made. I can't tell if that decision was made or not. uh So what was the what's the next step to arriving at a decision, yeah.

A

C

A

Yeah go ahead. I was trying to recap.

C

A

We're on the same page, so I think uh one of the big decision Point as Yoshi, was implementing Leia for uh authorization policies for Z tunnel. uh He needs to decide what is the contract between the control plan to Zeta mode right, so one proposal on the table was uh there's an internal representation which I think everyone reviewed two weeks ago now costing is more feeling strongly about. Why don't? Why not just reuse the existing RC policy from istio and have that present to the zetano and then zetano can process there I think.

A

That's all the thing we're trying to think out and it looks like yossi kind of agreed. That's the easiest way to get started, um although the is a little bit of challenging of. Would that work for Network policy down the road, but if we're okay with you know, just supporting the what istio supports right now worry about Network policy down the road when we need to implement it might be a reasonable starting point. That's what you know, I think about trying to decide.

E

If I miss anything.

A

C

John's, like the principal person who disagrees with that path, is that right, I'm.

A

Not sure if jonty's.

B

So great now as well but I, don't want to put words in his mouth.

C

G

I think, from my perspective, yeah, if you can just show us, the implementation, is efficient to just directly use the control plane, Proto I'm. Okay, with that, okay.

A

Yeah, let's do that yeah.

H

G

The impacted and then or Logic the implementation may not be that efficient and it's a it's actually not sufficient from the current proposed proton. That's what I can see.

B

Yeah I just want to expand on that. To make sure that's not the only um concern. I'm also concerned that it's not going to be safe to implement correctly. The obviously API is like a bunch of stuff that is not relevant to Z tunnel and it's complicated. It has all sorts of string parsing. That needs to be done as much as we can avoid parsing things in the Z tunnel.

B

There's less opportunity, for uh you know, cves, it's much more efficient, et cetera, so I'd much prefer that the Z tunnel just gets a minimum representation because remember if Z tunnel gets the obviously policy, it's going to need to process that into some other form internally, so that I can use it against requests. I. Imagine that for each request it's not going to go through the actual original authorization policy, as is and like try and compute whether it matches right it's going to have to convert it to its own form, anyways, um so I'd.

B

Much rather have most of that conversion be done by that control plane uh into an efficient form. That's efficient both over the wire use, your frizzy tunnel to understand um I. Don't think it saves us much time by using the current one, because we're still going after convert it. It's just whether or not it becomes a Proto or not, which is largely an internal implementation. Detail.

F

But Yoshi Yoshi go ahead.

C

So the next step to drive to a.

G

Decision I think Yoshi is so speaking about his muted.

C

Oh I'm, sorry I, didn't hear you good. Oh yeah,.

D

I think the authorization policy that uh John the attorney repulses will not have.

D

We will not have to do the processing that that you refer to, because this this is the part that is your table, will do I mean taking the selectors and namespaces prefixes and names prefixes. Those are kind of selectos information.

B

Proposal that I was arguing against was to send the authorization policy, as is so I'm, not sure how we can say that the control plane is going to do work ahead of time to process these things. If we're sending it, as is.

D

No I think really uh I I misunderstood the the part, because I thought that the suggestion was that the um the.

H

D

Part will be done by the eqt, and the utilization policy will be passed as he is without the irrelevant layer. 7 part, but as this without the threatening meeting need the need of the Satan and to do the all system of this Electro itself. They're.

B

Still parsing to be done, though, um all the fields even in The L4 Fields, the Aussie policy, represents everything as a string, so we may represent a cider as a string we may represent IPS as a string. They may represent a prefix of the string right. We need to process all that and if we're saying that we're stripping out all the L7 fields, we're either just stripping them out from the actual contents, but not the Proto, in which case z tunnel has to handle those in some way right.

B

Does it just ignore, like 90 of the fields and pretend they don't exist, maybe, but it's a bit suspicious from a design point of view. If we actually change the Proto to actually remove those, then we're basically making our own Proto and we might as well optimize it more than just stripping out fields.

F

But it needs to be equivalent, so we need to guarantee that whatever is the result, is functionality equivalent to what we have and we are not adding more stuff, because that was my concern with inventing on your protocol like Android filter.

F

Is that we we we may make it more complicated than it is I, don't think I'm against converting strings to to you, know, numbers and and sending them in a more efficient. But my concern was about changing the semantics of the of the authorization policy and creating something that is more generic and more complicated than than what we have.

G

I think the internal representation should make the invitation easier, whatever the implantation.

A

G

That's that's right, yeah, so yeah the the reason I'm talking about and what about is not saying. We need to have a different product to align with what the NY has it's, basically making the implementation much easier. Basically, the the mobile portal is optimized for processing this embedded and then all logic. That's totally designed for machine to consume, to to easy to enforce the recursion logic.

F

I strongly disagree that and full implementation is, is sufficient. I mean efficient would mean to use three and and all kind of efficient data structures to to map the cidrs. There are a lot of other things that go into efficiency, not necessarily writing interpreters, that is implementing some Android and other things. Recursively.

G

Yeah, it's not the only efficiency, implementation, I would say, but it is a pretty it's a well-tested and is currently it's proved to be efficient to implement in Amboy hey.

G

There are some grpc Library, also use the same logic.

A

Yeah, hey Louie I want to make sure. Are you the one raising the hand I want to make sure you have the mic because you've been pretty vocal in the chats too?

A

Oh, you don't have audio okay, okay, got you.

C

All right, while we're waiting for Louis to jump on I, I I, do think like the next step for making decision here is, if.

E

C

To change the API to get a written proposal, um because I now I I can sense that we're actually debating about different things like I'm, not I'm, not sure we're on the same page about even what what's being proposed. um So I I'd like for someone to leave this meeting with may I to do that. Probably shouldn't be me because I don't think I agree with it.

G

C

Who agrees with it should write it yeah.

B

Hopefully, you've seen that there's a big doc that is already proposing all this uh I.

C

Mean there's updates, but.

B

It's it's quite uh far along okay.

C

So the proposal essentially.

A

Followed this document- that's Yoshi's dog right at the end, I think John was taking many minutes. There was like four options from last meeting two weeks ago: Louie go ahead, pass the mic to you, yeah.

H

Yeah um so uh Carson it sounds like they're. Most people think that there should be a tailored representation right, I, think right, and there are a variety of reasons for that right. Even even if we ignore the selection mechanism, there are other normalizations of the data that need to occur for the Z tunnel to be able to perform its work like when we talk about comparing identities right.

H

We're gonna have to do forms of normalization of IDs right in the API right, whether it's a workload ID, whether it's a principal ID right, we are going to have to compute those right and those are not directly represented in the currently public-facing API LLC policy.

H

So we're going to end up with an internal representation anyway right a more downward facing API, so I think what we should do is what we we can start structurally with what we have right, but Fork it and then work on iterating the representations to be more easily implementable by the Z tunnel.

H

Yep right, so the control plane still has to do work like we're all in agreement. The workload selection like that can't be done in Z tunnel right for a variety of reasons.

H

We know we're going to have representational changes anyway, to simplify the work for Z tunnel over time right, particularly normalizing, identifiers, right IDs, uh and at some point we expect the Z tunnel to do things that are not currently in the altitude API, either Network policy or egress policy right.

H

So we may as well Fork it now and let it evolve, because it's not very complicated for the control plane to do the translation. Now we do carry a testing that, but we already carry that anyway, right because we have to do all the functional testing for this. No matter what versus the public API.

F

I completely I mean working with as it is and optimizing any changing. You know to have more efficient representation as long as it's equivalent and is not moving us into direction of envoy, which is a expression. Language I mean it's basically kind of cell and and other.

H

Experience yeah I, don't know if we need an expression language as opposed to just a declarative policy right. We I think that's a separate topic. We can answer separately from this, which is the representational discussion.

F

Yeah no I'm perfectly fine, with optimizing I mean to have a slightly equivalent functionality, but different representation or optimal hold for it. I mean it's, it's clearly easier better and it's not changing what I'm uh I mean. My concern was having an expression. Language basically sneaked into I mean an ebpf sneaked into into this uh proto-basically.

B

I agree with you Hassan and I: don't think the current proposed Proto does that and also the actual user facing RC one is. It has an expression language. So that was one of the reasons why I didn't want to use it, but specifically that so yeah.

H

That's conditioned right, which is so.

B

I, don't think it does full cell Expressions.

H

No, it's a limited, subset, okay, yeah logically so right, right, yeah.

F

Which ones employee one is closest.

B

No, the authorization policy user facing API- you can do things like I'll- send an example. Yeah.

H

The from to and where the where is a.

F

F

Expression then it becomes cell as it is. You can translate it well, yeah, I, guess you are right, it's still a translation, but it's a scope that I'm concerned about, because today yes, it's where, but it only have five different things that you can put there and none of them already applies.

H

Here for any attribute you want to requested you.

F

Know the documentation is clear that only if those five attributes are supported and right.

B

But we still have to parse them and then say like: oh that's one of the ones. We don't want and stuff so I'd. Much rather have the control plane, parse it and.

F

uh To pass them into those optimization just not to allow arbitrary Expressions, no.

B

Absolutely I think we want Z tunnel to not be arbitrary. We want it to be the least generic API, oh not the least generic, but like we that's kind of the intent of the workload as well right, we're not putting labels just because they're there and we can we're putting the fields we need and only the fields we need to implement the Z channel. So.

F

I think we should do this yeah.

H

So you'll see I think you have a direction right at a high level.

B

Yeah I was going to agree, I was going to say the it seems like the outstanding concern really is that the Proto, as this maybe can't represent all the current states of the API but I, think that's that's minor issues, not fundamental issues, so we'll just need to make some tweaks to the Proto, um but then to me looks good to me once we do that.

F

Okay, since it's tested and prototype and then extend it with whatever is missing and make sure we don't expand the scope and we don't add anything that will be represent, something that is not represented in the API until we have a clear need for it.

A

um Okay, cool sounds like we have consensus and you'll see. Do you want to say anything.

D

um No, there is one more question that actually five minutes is is enough to discuss that, but uh did the uh Thursday stimulator that John did uh of the comparison? Whether we will have the references in the workloads of the or vice versa and I know that in.

B

H

D

Last meeting we agreed that we will have the references in the rules the Outback resources themselves, so that John simulators showed slightly on I, guess slightly more efficient. If we will have the references there from the workloads to the uh to the rules, um still open question.

D

So do we want to to design that to decide on that, or we want to postpone that to a later stage and know that maybe on the implementation side, it will not have the pH and differences. But we if there is like a clear answer that we want to to give to provide now it will be and better.

A

John, do you have any comments.

B

Yeah I mean I like the proposal, that's in the doc right now, uh but I think I'm a bit biased because I think that was what I've suggested so I, don't think my opinion's terribly useful uh beyond that.

A

Foreign, who has a different input on that.

D

Actually, what we have today in the document is the rules reference in the workloads right, because we have the workloads filled in the.

B

I was assuming the studio was, was done.

G

Yeah sorry, yeah, yeah I, think I added a comment um yeah just uh to show an example saying that the country Proto can probably cannot be used to express order. Existing is the oscillation policy.

B

I think that's a different concern limit, we're talking about whether how to say that this policy applies to this workload, not the actual rules themselves. um Oh okay, okay,.

G

B

Make sure, obviously it has to be able to represent all of them, so we'll make sure that that happens, and that was a good good call out that we're sorry.

H

It's been a while since I looked at the talk is the current. The adoptions are either the workload refers to the rules by reference, the rule gets embedded in the workload right. So it's not by reference or there's the workload reference. Sorry, the rule references, the workload set right. Those are the three constructions.

B

I think we've narrowed it down and refined them a bit. So we know for that Global or namespace rules. There's no need for anything to be in the workload um the. So the question is for workload, selector rules. What do we do and one option is to put a list of workloads into Aussie policy and the other one is to say in the policy. This is a workload selector one defer to the workloads and then put the list of workload selector rules in the workload.

B

um So it's a bit wonky because you like the implementation like in some cases, you look only at the rule. In some cases you look at both um the reason why we did it was. We did some simulation of in terms of turn of things updating like, because policies are bigger uh and yeah. It ends up being that it's a bit more efficient to update the put it in the workloads because policies don't change often, but workloads do change often so, basically anywhere.

B

We have a big list of workloads we're running into tricky territory, because now anytime, one of those workloads changes which is often you have.

H

To push it's the same as the service.

B

Exactly exactly exact same thing,.

H

So basically you're saying workload back. Reference to policy is probably the best.

B

Yes, but scoped, so like the common cases, you have a namespace bound and there's no need to have that which would also.

H

Increase yeah a workload has a back reference to a namespace effectively. The namespace can have a back reference to a set of policies. Yeah yeah.

F

Labels we have workloads, have references to policies, it's.

H

E

Right folks, I'm getting kicked out of my.

H

A

Okay, so John just making sure I understand you're. You are saying this is more efficient based on your test.

B

E

A

F

A

F

One one more point on what the living was saying about: it's not representing the full power of istio API that we have today. uh We need to identify what is not supported for sure, but we could as well have a discussion if we want to support the full power, because it's an L4 policy there are user is aware that there are some changes. We need to document that some attributes are not going to be supported, so we we have an opportunity to simplify as well and to reduce.

B

That Institute in the dark there's a list of what parts uh like what attributes are supported, which is obviously the outboard part. I, think the thing that Lee Min was worried, isn't representable as some of the like there's a bunch of like, and an ores, basically and.

F

B

Set of those I feel like it would be, it may be a bit odd to restrict those.

G

G

Exactly yeah so I'm not talking about the the properties, L7 properties, we need to remove, but it's basically the other level how to express the end or combinations that part I think we we need to support foreign.

B

For identities, I'm curious what we want to support I feel like those three options is one istio shaped spiffy, arbitrary, spithy or arbitrary anything.

B

uh Today we only support the Eco shapes 50, that has you know the namespace and service count and the shape that we expect yeah.

G

Actually, for the principle, um the only thing we pause is only when we need to support the namespace level policy. Then we.

B

I don't mean today, I mean in ambient NZ tunnel and whatnot.

G

But isn't ambient the first Target is for Easter policy.

B

ah Yeah, that's what you mean.

F

No, but it is also the authorization that you need client authorizing server, so secure naming yeah.

B

That's yeah naming was the main thing actually and.

F

Secure naming does already the essential rule does what arbitrary is done? You can put the.

B

Destination row won't be impacted by Z channels. Retailers won't read destination.

F

I mean if you have a L4, doesn't have to to verify the the identities appear and doesn't respect destination, rule service, sun.

B

No, it does not it's always using h-bone if you want to configure destination rule to add that that would be like a waypoint or sidecar level. Config oh I, see yeah.

A

So, even for layer, 4 traffic shifting because I thought that's in citano I mean I, know it's Woods.

B

Only does Odyssey policy, that's the only API.

A

Oh okay, because.

B

A

Read our initial launch blog I think we had uh Justin will know for sure I think we had layer for routine as well in cicano in the Lego layout.

B

I, don't think I would have let that go out on the blog. Let me see.

A

I mean a nice I got it wrong. It.

B

Says TCP routing it doesn't mean that it's customizable, oh.

A

Okay, yeah, okay, you're right; it's not customizable, but still for TCP routing right, which will be layout, routing sure.

B

We route it, but you can't customize it with any apis.

F

G

F

I I I mean these two API is probably good enough for to get started, but I mean you still a sun spiffy.

C

F

But I think if Z tunnel is to be interoperable and to work with other vendors and will be adopted by JK, Gateway, vendors and so forth. We need to give some flexibility in in Secure naming at.

B

Least one you know I think you're, probably right. The current implementation doesn't because we don't actually send the identity as like an opaque string. We send the service account and namespace and we actually align that in some cases, as an optimization.

F

It's getting nasty if you don't.

B

Yeah so yeah, it's too fair about that yeah; okay, that that probably makes sense thanks.

A

All right are we done.

H

A

Thanks everyone for joining happy holidays. Bye now see you next year.