Kubernetes Network Gateway API Special Interest Group, 10 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20221010

Description

SIG Network Gateway API Bi-Weekly Meeting for 20221010

A

Foreign, hey welcome to the Gateway API community meeting for October 10 2022.. We are getting awfully close to kubecon thanks to everyone who made it here, uh just a few things on the agenda today, but before we get to it, uh just a quick reminder that this is just like any other kubernetes community meeting Guided by the same code of conduct, which is generally just to be nice to each other.

A

um There's a lot more details. If you look up the kubernetes community code of conduct, but I think we've all been very friendly. So another reminder that please, uh if you have anything to discuss, don't hesitate to bring it up, you can anyone should be able to edit this agenda or you can drop some Link in chat as well or just speak up whatever works best for you um with that, let's get started on the agenda.

A

uh First up, we've got kubecon uh we're wow a couple weeks away so hopefully see some of you. There uh we put a. We had a couple cfps for contrib Summit. Both of them got in uh one of them is an actual talk of sorts that we need to give uh for. Anyone who hasn't been to contrib Summit before it's a pretty informal thing uh but I am very much looking for uh for different contributors.

A

That may be interested in helping present that so, if you are planning to be at kubecon and if you're going to be able to make it to the contrib summit on Monday I'd love to get some new faces in front of the community, especially other kubernetes contributors and just we've got a chance to share our experience working with crds with this API.

A

uh So you know, if you're, if you're able to make it uh reach out to myself or Shane and we'd love to fit you in and- and you know, have you help out with this talk again, it's a pretty informal thing, but I would love to get some other people uh speaking about Gateway API um and uh just not put anyone on the spot. But does anyone want to volunteer now any chance.

B

I think Phillip Platt and chat did.

A

Oh yeah, awesome: okay,.

C

A

C

Yeah I'm not sure, actually that I volunteered to to to to oh I, misunderstood okay, yeah.

A

Yes, well, this is a good intro anyways uh welcome Philip, uh maybe just give a brief, intro uh yeah. That was a bit yeah.

C

So so I'm Phil cloudy and I um I'm a product manager at F5, um and there are a couple of different groups at F5s that are interested in the Gateway API.

C

um uh You guys have probably seen some stuff from our uh nginx Ingress team, um but I work specifically with uh uh in the service provider area like Telco and 5G, and you know, as you guys I'm sure, are no doubt aware.

C

uh You know all of the service providers are launching 5G on kubernetes and it's just starting to happen, and so uh you know I've been working for the last couple of years on a product we call SDK or service proxy for kubernetes, which is about the sort of Ingress and egress like tying together, North and South uh bound traffic for launching 5G um and I only became aware of the Gateway API a few months ago, um but it strikes me that's what's going on here is actually kind of vitally important um to the work I'm doing- um and you know, we've already done some like demos and things to get our product.

C

uh You know where we can use the Gateway, API and stuff to show it off um and um we're getting questions from some large carriers about whether they should be pushing their vendors to comply with Gateway, API et cetera, et cetera, and so you know, I think I- think it's a direction. We're very interested in I I have also on the phone Quang uh who's on.

C

My team and you'll probably see some other folks too, but this is something we're really interested in and I'm actually going to be at kubecon at the cloud native Telco day uh on Monday um and I'll be presenting actually about my product and the sort of networking in kubernetes, 45g um and I'm hoping I can you know meet some of you guys there at kubecon, I, don't know what time of day the the stuff you're talking talking about is on Monday but I'll be presenting just afternoon like one.

A

Hey that that is awesome, that's a great intro. Welcome everyone from the team excited to see where that goes. I've I've just had a few other people reach out about uh Telco and how what that means for Gateway API, so I would be good to make those connections and see where we can go with that um and I I. Imagine I'm, not the only person who's had those discussions, so yeah, that's awesome, I I know for contribute, Summit, it's it's basically an all-day thing. I.

A

The schedule is supposed to really be released sometime today, but at last I checked it hadn't been, but we should know soon when these things are going to be. uh If not I know, I've I've been trying to set aside time on Tuesday uh and I. Think some other maintainers have some time on Tuesday as well to just have some informal meetings and discussions.

A

So if you happen to have some time on Tuesday free I know we'd love to meet then too, um all right, so yeah just uh awesome, don't don't hesitate to reach out in uh Gateway API slack uh and uh yeah we'd love to love to follow up yeah welcome.

B

A

You awesome uh and so yeah just uh yeah one last reminder if you are interested in either being part of the working session. Hopefully that's many of you and also, if you're interested in helping to present our crd talk. I would would love to hear from you again just reach out in slack or in chat or whatever works best um Nick. It is great to see you alive again. Welcome back yeah thanks.

D

Cool I haven't I, I talked to Rob about it, but um yeah for those of you who don't know. um Yeah I went to I, went on skiing trip a little while ago and have blown my um snapped. My ACL and torn my MCL on my left leg and tore my MCL on my right leg. So I am on crutches and T-Mobile and will not be able to make it to kukon, which I am extremely upset about. um So.

B

D

B

um I'm, sorry, that sounds quite painful.

D

Yeah yeah, it's pretty painful, but uh yeah um uh Lewin just asked. If we can attend the working session remotely through Zoom uh I personally would love it. If I could at least be a fly on the wall, uh you know so that I can. Even if I have to get up at some stupid hour, um it would be nice to uh try and or at least if it's, if it's on zoom and recorded at least I can catch up um yeah, uh so yeah I definitely um would have loved to have been there.

D

C

Yeah thanks Mike for.

D

Also for getting started, I can see you getting started on implementing the uh one three six four stuff as well. Thanks.

A

Cool yeah, uh so yes, big, big, plus one to feel better soon. Nick that sounds awful, uh but uh also I should follow up. I've been talking with I. Think Jason and Bob are the two people that I've been talking with about contrib Summit I'll check in with them to see. If there's any like good way to do that, but yeah I'd love to have some kind of hybrid, so much of the conference is hybrid I would love to see if we could make that happen. For this particular part of it.

E

A

Cool uh and maybe maybe just uh reach out on slack or post a message or something if you're one of the people that would be interested in you know doing something but aren't able to make it do contrib, Summit or kubecon in person, and we can try and set something up that way too.

A

Yeah yeah cool all right. uh Next on the agenda, the Ingress to Gateway repo is live and I like you. You are not wrong. There's nothing here! This is just from the template. I still need to make a PR with actual code in here, but uh the maintainers here are the same. Maintainers of Gateway API, uh so I think we'll cover any one. I think this is going to be a pretty small project, uh but I think we can cover it under the same meetings.

A

The same process, the same everything as Gateway API itself, um yeah I'll, try and get a PR together. You know for for context. This is the thing I presented last week: I want to say of just a a very work in progress tool.

A

You know it works, but barely uh that uh we'll take Ingress resources from your cluster and output, equivalent emo for Gateway API resources, and it understands some subset of uh implementation, specific annotations, so yeah, that's the thing that I'll try and get a pierra out for soon on this repo, uh but uh again for anyone, who's, a Gateway, API maintainer, already you've kind of been volunteered to also maintain this. Thank you, um but uh also anyone else is welcome to just pay attention and review.

A

Any changes, contribute I, know, I, know the last time I presented this. There were a few people that that seemed interested in in helping out. So by all means uh we can always use more contributors, and this is a great opportunity if you're new and just want to help out um so yeah, that's Ingress to Gateway. It is ready for contribution. Well, I need to make a PR, but then I'll be ready for contributions yeah and then, with that I think, let's get into the 060, Milestone and I think Mike.

A

Let's just start with uh your thing on get 1364 uh and what uh what we've got coming up next.

B

Sure so yeah I just broke out two PRS and one issue that was not addressed explicitly in the Gap, but it is kind of a corollary from things that got uh I think the suggest should be necessary.

B

um So I think that those so I closed. Two of my older issues. They were kind of like sprawling meta issues, uh so so these three should be relatively direct and actionable uh to get into the 060 milestone.

A

B

This is fantastic gateways, uh the other one is adding accepted to listeners and the third one is adding a pending status for appending reason for all the different conditions uh for each resource, because setting a reason is required for a condition, even when the status is unknown.

A

Oh interesting, okay, so this is the this is the one that requires a bit more discussion. Yes,.

D

E

B

D

The default value we have when it's condition state is unknown. You need to have a reason, uh and so the reason is on status, unknown reason pending.

A

Okay, got it: okay, as I see I, understand now, yeah.

B

It is where we're currently studying not reconciled for as like in the actual Cube Builder defaults for at least gateways and waiting is kind of a weird, similar. Looking thing.

A

Yeah, so is this: is this pending reason intended to be used exclusively with the unknown state or their.

D

I think so Mike. What do.

B

You think I think so um there is some current usage or it's currently there's a listener condition reason pending that I'm not entirely clear on if it should be used in some other way, I think it's associated with false, but I think that's just more of a documentation issue than like an actual different use case.

D

Yeah I think in general the pending reason seems to fit the best with the unknown one I, don't think you would have it pending as like a we're waiting for something to happen that fits best with the unknown State, not the true or the false State, um true or false kind of implied uh strongly imply, like the any operations associated with the condition of terminated, and so action needs to be taken to change the state, whereas pending implies a way to know yet yet, which is the same as unknown.

A

Got it so this replaces waiting and not reconciled with pending, as kind of.

B

D

A

Okay, yeah makes.

D

Sense, just one more place where we're consolidating the different reasons that we had across different conditions to to be the same reason across different conditions across different conditions that are used in different places like the Gateway class conditions, the Gateway condition and the route condition. We want them to have similar, States and similar reasons, so that when you're. Looking at one thing you can you know you can transfer your knowledge about one thing to another.

A

Great perfect, that that makes sense, uh Mike or Nick. Can you use any help with this I know? There's a lot going on here. Oh.

B

I would be happy, for this is relatively straightforward if any new contributor is interested in picking this up um and the other two I I. Obviously I have a question that Shane started answering about if there's any specifics, as far as like Cube Builder validation or anything like that for just like deprecating things properly, but those two I could probably uh finish up and check myself.

B

Thank you and there's at least one other one that probably needs a PR around the like HTTP route rules and the changes from The Gap and just making sure those are all clearly documented um in our actual docs. That one is much more involved. uh The the Gap spells out well, but but the documentation updates are going to be much more involved and comprehensive. I think so. I haven't uh done that and I'll probably not have time for that. One I.

D

Will have time for that one! That's fine! I can take that one.

A

Awesome cool um this. This seems like one of our the biggest things we have remaining in. You know the 060, Milestone and actually yeah. Let me pull that back up. I I. Think. A lot of what we have left is in some way tied to status, and you know I think we said this is kind of non-blocking.

A

Crpc route is almost done, there's just one more docs PR to get in uh and then almost everything is related to status now, so anything we can do to help, and this is that you know I'm not trying to rush anyone either. I know that things take time and we don't want to rush to release out the door um so just but yeah. Let us know how we can help, uh and it sounds like that. So it sounds like everyone. It sounds like all the pieces of this Gap are accounted for in some way right.

A

It's and Mike you're doing a chunk of it and Nick you're. You've got the rest roughly, except for that. One issue that some other contributor could take on is that I.

D

Think the last the last thing from The Gap is is that at some point we have to flip the conformance tests to check for uh programmed rather than ready, that's the big sort of broken change. um We.

C

Don't actually test.

D

We don't actually conformance tests for accepted anywhere. The only the only state status that we're using performance test is really at the moment.

B

That was what I found that surprised me is we yeah. We have accepted anywhere and yeah want to add that potentially, that might not be a bad thing, but it's not breaking at least okay.

D

Yeah, so we could. We could certainly phase this and have it be that you know for o60, we put you, we put it that you must set accepted and we'll check for accepted in the conformance tests um and then but we'll leave ready as it stands and then make it that 070 is when we break ready and we put and we Skip, and we flip that to programmed and have and move ready to Extended or we can do it yeah. Just like that, it's more the only reason I would suggest not doing it.

D

This time is because just the amount of work that's required to flip all the performance tests and get it and review it and do all that sort of stuff- and then you know, is, is a lot um I I kind of would prefer to do it all at once, so that so everyone has to do like one big update to the status calculations, um but it's just going to depend on how if we can get that in in time.

D

So it's just so maybe we hold that in our back pocket and if, if Mike and I managed to smash the um the other stuff pretty quickly uh and we're and I'm sitting around, you know the week before kubecon with nothing to do. Then then, maybe maybe I'll try and get it in then, because since I'm not traveling I can uh you know.

D

I I have a little bit more bandwidth um that I'm not going to be like preparing to travel and traveling and stuff so yeah I I can probably push the release buttons uh just before qcon as well, um if required. So it could be that we will have enough time. It just depends on bandwidth, um but I.

D

Think the back backup plan in my mind is that we go with um I think we definitely want the accepted changes in for this for 06 over definitely um and and we should have conformance tests for accepted, you know 60 and then we hold the you know we wait and see how much time we have for to flip the ready Behavior over.

A

Yeah I think my bias is to my preference here is just to go ahead and wait until everything is ready. uh You know, I I think this is a very large change, I like to make sure it's it's well thought out and that we have conformance test coverage of everything that we're trying to change.

A

uh If we don't get this completely released before kubecon I feel, like that's acceptable, you know I'd love to have say an RC out or something before kubecon, but if we don't actually have the full thing out that that seems acceptable to me.

D

B

That makes sense to.

D

You yeah cool yeah, so.

C

D

So, let's uh so to just wrap this wrap that statement up in uh so um ready will will be changed to programmed as a part of the o60 release. It may not happen before kubecon because timing, but uh but we will, but we will make sure that um that ready gets changed to programmed with conformance tests updates before we actually cut the final o60 yeah.

A

Yeah that makes sense to me.

D

Is that uh yeah are there? Are there any objections from anybody about that plan?.

D

A

Okay, I'll yeah I'll take silence as a good sign, but please uh anyone on the call don't hesitate to uh to speak up if, if anything sounds even a little bit off, um do you let.

D

Us know yeah, yes, I remember, for everyone who's an implementer. This change is going to be a big one. um You will have to stop programming ready or you can keep programming ready if you want, but you will need to program. The programmed condition as well like the programmed condition, will be what the conformance tests used to to sort of be to, as the signal that hey now I can actually start checking that your thing is conformant rather than ready.

B

A

Cool thanks uh thanks Nick and Mike for taking that on that's a ton of work uh but excited to to get it through um yeah. Let me run through the rest of the Milestone items here. uh Sorry Mike were you about to say something: I may have missed all right cool um all right, so this is status. This is grpc, Route uh I think we're good on that front. Thank you. Richard I saw one more uh PR update from you that I need to review, or anyone can review.

A

uh Richard has done some great work on docs I. Think grpc route is going to be one of our best documented resources as it graduates to Beta. So, thank you. um Then. This one is a nice to have. We had a volunteer, but I don't know if that volunteer has made any progress.

A

Yeah I can follow up. um But again this is something like we've considered, non-blocking uh more status status.

A

Oh there's a PR for this and I missed it. Sorry uh Shane you've reviewed this PR. Do you remember the state.

D

A

Was the one wasn't.

D

That didn't have the that yeah images as separate tags. No, it had.

F

Them as separate tags, or rather we wanted a.

B

Multi-Arc build so it'd be a specific um yeah. That's where I last left off with it was they had put in the pr making separate images for each of the different architectures and we were looking for a um multi, a multi-arc build okay.

A

So we probably just need to Ping on this PR again, it looks like last activity was a couple weeks ago: okay,.

A

um This one I just created, promote reference. Grant debata we've been talking about this for a minute as something that we want in 060, but I don't think we ever had any issue to track it. So I created that I think this is fair game for anyone who wants to do it.

A

um Yeah I. Anyone that wants to volunteer just uh add a comment and again love any contributions on this one.

D

Yeah, so the um so this one is I'll update the types and then and then just check that the reference that we have, that the conformance test cover everything right again, I think we have pretty good Converse coverage already, but yes,.

A

uh Yes, actually pretty good coverage on reference Grant. The weird thing I didn't really know how to explain this, but uh John went through a couple weeks ago and did this kind of clever thing where we're using type aliases for everything in Alpha two. This makes it a bit easier to implement if you're trying to support both Alpha 2 and beta 1., but it means that the types files are not an exact copy anymore. It's uh instead, you've got to do some type aliasing.

A

Instead, it should be a much smaller file but again type that type it leasing involved.

A

So that is a little different.

A

Cool uh and then the next item up here, more status status and this one from Mike I think Mike. You said this one yeah. This is just waiting for someone to volunteer.

D

Okay, I'll uh I'll make an issue for the um for the other uh route updates. The route rule updates so that it can be in here as well.

B

A

All right uh so with that I think if there's nothing else, that oh no there's one more thing thanks Candace and then we'll jump into triage, uh all right, so 1282 background properties, uh maybe Candace!

A

um Do you want to give a bit of an update on this.

E

Last week, I I am made a pull request uh to include the implementation for what we had been discussing in the meeting for backend properties. The back end properties are the way that we decided to go forward for TLS um re-encrypt, also known as Upstream encrypt and um I got some feedback from it from a lot of people.

E

Thank you very much for that um and I made some changes, but the one that I'd like to spend just you know five ten minutes on in a face-to-face meeting is what do we call this field because I mean I I just want to make sure that it's something that everybody can um you know can can understand when they see it for me that that word was re-encrypt, um but I unders completely understand that that's not a a common way of looking at um the encryption that happens from from the back end, uh sorry from the gateway to the back end, as opposed to the encryption that happens and terminate, which is from from the from the route to the Gateway or pass through, which is doesn't stop, doesn't stop in the middle encryption, um so I noticed in our docs I.

E

Think there's a link here uh to our Docs, um so we use the terms pass through and terminate, um and what I was going to suggest was something like forward or extended.

E

You know, rather than re-encrypt or rather than Upstream encryption or anything like that. So, as you can see from from this diagram, what I'm talking about is is labeled as Upstream here from the gateway to the service.

D

Yeah, that's um definitely some uh Envoy terminology creeping in there because that's how all the way it talks about it, um yeah I think it's it's a really interesting naming problem, um I'm! Actually, I I! You I'd actually be a little bit more kind, because this thing is I'm already a back-end properties thing. um It makes sense.

D

It makes it actually makes sense to me what Tara was saying about just calling it TLS, because this is then the TLs properties of the back end, because you're describing the back end, you're, describing the service uh and, and so this and so having a btls I. Don't I think because it's a separate object. It's okay to use the word. um That's sort of my initial feel, um but I think I.

D

Think your point is fair, that it is reusing a word but I think it's it's only because we've got it as a separate resource, a separate object.

E

We use yeah, we use the word TLS as a listener property um and it's for everything except re-encrypt.

E

So if we use the word TLS for just re-encrypt in this object, are you sure that's not going to I mean to me? That's confusing I'll, just I'll just say that yeah.

D

Yeah fair enough I mean in my mind the reason to do it. That way is that when you've got the tail listings on, though it's not it's, because the listener has TLS properties and you're describing the TLs properties of listener.

D

In this case, the back end has Taos properties and you're, describing the TLs properties of the back end right, like you're, saying like to connect to this service, you need to use these TLS details and so just having a btls kind of makes sense to me, but I understand what you're saying and I'm not like I'm, not being like you've got to do TLS I'm, just it's just like to me.

D

It makes sense to do that, and it also means that you you're sort of uh reusing a word means that your people can kind of expect that the behavior will be similar when you put the TLs properties on The Listener and the TLs properties on the back end. It's like this is the TLs details you use to connect to this thing.

D

I think you would need explanation in the docs, obviously, but but because I think the all of the things that that you're saying like I agree that recrypt is not it's also, not that great. But you know and and say and you other options are then sort of you're sort of saying, like you're, describing the behavior that you're getting rather than a property of the the object.

D

If you understand one of the the decision there, it's a very subtle distinction, I know, but but like that you're describing the the behavior that you're implementing rather than a property of the object, and so like does that make sense to anyone. Or is that just me talking at my house.

E

No go ahead. Rob.

A

I'll figure out how to unmute myself at some point sorry, um so yeah I I was actually of the same mind as Nick here at least initially, and now I'm at least a lot a little unsure.

A

But to me it seemed like yes, the most generic way to represent this is this is just TLS information about your back end, but I do I do understand that it's going to be confusing if we have a field of TLS property, destructive, TLS properties on Gateway listener and a separate set for a back end and there's zero intersection between what they allow to be configured, which I think would be our initial starting point of there's and and I think as long as we have a path where they converge or where there's some more similarity.

A

Maybe that's! Okay, but I. Think if I'm understanding what you're saying correctly Candace I think what you're saying is that at least initially the concern would be that these would be called the same thing but be fundamentally different in what they enabled is that.

B

E

B

E

That's what I'm saying that's one. That's one comment that I had on it. In the end, it doesn't make a big difference to me. um You.

B

Know we'll just.

E

Name it what it's named, but um if you want feedback on what seems to be understandable, then I, just I just made those suggestions of um you know a for something that that you could put in this document that we're that you're, showing on the screen. Now that would describe to people I mean you couldn't put well I, don't know if you would even describe it in here.

E

You'd have to rework this this document for sure, because TLS mode applies only to The Listener that doesn't apply at all to uh the big, the back end capabilities, which only have one TLS mode.

A

Now remember we had this discussion uh back in the day when we were talking about different options for TLS mode and re-encrypt was one of the options we considered but again, I think at that point in time. The the idea was that we really just want to describe what happens at the listener, and you know on on the way in from client to Gateway and then leave gateway to service for some other configuration such as now backend properties, so I think in. If we continued with that line of thought, then nothing here would change.

A

We would just add a new section that described how you configure gateway to service TLS.

D

Yeah I mean I. Think importantly, back-end properties doesn't make one of the good things about having it be separate is that it makes no representations about what the protocol on the business side is, but, like it's completely valid, it seems to me that it should be completely valid to you. Have you come in on clear text and then encrypt to the back end right, like it's they're completely orthogonal concerns.

D

um You know whether or not the listener is encrypted and whether or not the back of the connection to the back end from the Gateway is encrypted. um Would you do that like have clear text, HTTP and then https to the back end that'd be super weird, but hey like by that, but having them. Orthogonal concerns means that it means that you don't need to like intertwine the two things sorry I spoke over you. What were you gonna say.

E

I agree: I, don't I! Think that sounds weird, that you would only do the the second hop encryption.

D

Yeah but the um but in my, but it really makes sense to me that the the the concerns are orthogonal right like it, that the whether or not the back end encryption happens or not is is a completely separate decision to whether or not you're having Christian at the um the uh um listener.

E

Do you I mean, do you mean in.

D

E

Of who would who would apply that like? Do you mean that it's only the application developer? Who would.

D

E

You can configure uh The Listener and it would be the the cluster admin who would configure the or vice versa, who would configure the second hop yeah.

D

So, in my mind, the the person who owns the service owns the back-end properties for the service. A person who owns the Gateway owns the TLs properties for the listener, so the cluster admin owns The Listener owns like owns. If their cluster admin owns the Gateway in The Listener then, is their responsibility. What certs are used and how that TLS connection happens and then, as a as an application developer, I can say well, I want the connection.

D

I want the connection from your gateway from the gateway to my back end, to be also to be TLS and that's within my control and this. Thus the back end properties is mine and that's another good reason to have the the two things be orthogonal is, that is that it lets you split the decisions about which things are TLS to the to between the personas.

E

Okay, can can you show the um the pull request or I can yeah.

A

Oh either way, uh let me uh let you be co-host and then you should be able to share away as well, and that might be easier to highlight in the areas you want to I think you've got to stop sharing yeah thanks.

E

E

A

There have been some good comments in chat here. um I can try and go through those soon too.

E

um Yeah I did I did make some changes already. There's some I I wasn't so sure about, um but we don't have to talk about it in the meeting. Necessarily um do you wanna I mean what I'm talking about now is particularly um the use of the word. um I use the word re-encrypt to to Signal this, but let's look at the whole. Look at the whole thing actually.

A

Yeah somehow we lost a lot of comments along the way, but uh that's GitHub but uh yeah just I think yeah. You change it to encrypt I've.

E

Changed it to forward actually, but that you know um that's what we're discussing now.

E

um So this is I mean just to remind everybody who hasn't had a chance to to look um we'd, be using this back-end capabilities um that has um just basically the spec and the status, um and the spec itself is what uh contains the configuration for for the re-encrypt section, plus a back-end, Target reference, and then encrypt type is what has you know, the information specific information that we'd be using for that second hop encryption.

E

um So what we're kind of talking about now is still can't get that that tab thing to work there. Let's start it the the name to put on this.

E

B

E

If we, if we just you, know substitute TLS there, um there are, as I mentioned, there are other places where there is a TLS object um and putting it here. If that, if that works- and everybody is okay with it, then I can I have no no problems doing that, it's just going to be me who's confused afterwards. If everyone else agrees with it,.

D

I guess the question that I would ask is: does this? Does this type here actually need to be different to the one that's on listener?

D

Couldn't we reuse the same type as of the one? That's on this note here, because you're configuring, the same TLS settings that you do on the listener. On the back end.

E

I, what don't think so uh go ahead? Rob.

A

So currently on Gateway, we don't have any kind of like clients or we don't have a CA bundle that I'm aware of um which I think would be important here, uh but I I think that could be a cool goal because it does seem like maybe.

E

A

It would be very confusing yes, but uh if, if they could at least start to look similar in their structure, um I guess yeah you're right, Mike is commenting in chat. The TLs mode would not be applicable that that's a good one.

E

um I mean unless we decided to you know, just terminate us through and re-encrypt, but you could only use.

D

I, just I just wanted yeah there I just wanted to have asked the question because, like in my mind the one of the best things that you can do with an API like this is to any time you're talking about two or less settings have very have the same or similar keys. Because then it's it's easier. There's less of a conceptual leap for you to understand like what you're talking about and I. Think in my mind, that's the reason to sort of have it be like the this.

D

This thing, configures your TLS and you've, got like the thing that lets you specify the certificate. Like the client, you know a client certificate, that's used and uh um and a service certificate that's used. We do have outstanding issues to allow for client certificate for for setting like a CA for clients. So it's on the listener.

D

um You know- and we do want to do that at some point and so the fact that we're going to have to do it for the back end like says to me: well, hey, looking ahead, we're going to need to do this for the listener at some point. If we name this thing, similarly to The Listener one and give it some new fields that we then later on backboard to the to listen to one and sort of harmonize the things later, then that you know that um yeah.

E

D

My mind that makes sense right because the listener has like this is the the TLs stands are in that case, for both of these things configures the TLs details. You need to use to connect to this thing, either The Listener or the back end and I mean if we just like uh you know, it describes the TLs properties of the object, and that's that's what I like about it like Pro, describing the properties of the object is what kubernetes specs are supposed to do.

A

I think one one thing that feels weird to me is- and maybe this is me just not completely understanding, but the idea that you would specify both your your client cert and your back insert in the same place, but make and and I guess this kind of Tran translates through to Gateway To You Know listener TLS configuration like you're, saying Nick of like can.

A

Can we get to this point where the same the same set of config works for both and that, like the same same idea for me too, I would love to make that work. I'm, just uh I'm, not sure right now,.

D

um Yeah yeah I mean I, think it doesn't make as much sense in my mind, to have the clients the specific clients that must be used be specified for the listener, um whereas in the the back end one the client search that you've got, there is saying Gateway implementation.

D

Please use this specific client search to connect to this specific back end, whereas in The Listener case you, you don't generally want to have a one-to-one pairing like that you're always having a many-to-one pairing where you're saying you know we're going to have some arbitrary number of clients connect to us, and they all need to be validated by this ca for the for the listener client search case, you want to see a Point, not uh not a back, not a client-side point for this case. You do want you having a client.

D

So just saying is a place to supply the client so that the Gateway needs to use to connect to the back end rather than something else. Yeah.

A

In the in the world where there are, you know, 10 different gateways that all end up forwarding to the same service extreme case, but theoretically could happen. It seems like the ideal implementation of that is each one of those is using a different client is, and that that would not be something representable with this config. It feels like the client served in that case is actually in the wrong place.

B

D

So and then yeah yeah, that's a good point, so you almost want the client search to be on the HTTP router on the or or configured on the Gateway itself. Right like yeah, or something like that. um You know Etsy yeah,.

A

It's like the Gateway in that case is is the client and it should have its own identity. um I, don't know, uh there have been some great uh comments in chat too. I want to make sure you know uh Mike Micaiah, Lewin John, and he any comments you want to raise out loud.

A

G

Yeah I I just have um in my mind you think that it's more like the transport property between Gateway and the back end um I'm, just curious, maybe John can come, and how does the ambient solve this because you got Waypoint connecting to back end is that you can leverage that, like a transport, you got this Edge phone transport people, whether there's something similar to that way.

F

Yeah, so one thing we've talked about in the gamma group is that things like mesh mpls. um We don't want that to be a part of any API. That's not what this is mesh mpls or maybe they don't even use MPS. Maybe these wire guard or ipsec or whatever right, um that's not what back-end properties is. The back end is like what the application actually does and if the service mesh wants to Tunnel over heb2 or use bioguard whatever that's that's up to them. It's kind of orthogonal.

D

Yeah I think that's exciting.

A

So just you know.

D

Sorry go ahead, yeah, so what so? What you're saying there John is that the the back end properties that we're talking about here in the back end capabilities, we're talking about are these are the certs that if you connect to the port that you're given on this on this service, it will expect you to you to connect using TLS using their sports.

D

That's what having this stanza set- and this thing implies- is that if you try and connect to a port directly running on this service, then the service like running inside the Pod will have these TLS details right like there's. No, this is not like the. This is not some abstracted thing where the there's like some implementation, is doing some magic stuff for you. This is like this service running inside. The Pod is actually presenting these TLS certs. As part of this thing, and that's why this is a back-end capability.

D

Does that make sense.

E

Are you talking to me.

D

I'm kind of asking generally um like the um yeah, so I think that's what what John is saying is like yeah, like the for the mesh case.

D

One of the points of mesh is that it's you know is that it's invisible and happens without user intervention, and you don't need to configure anything for it to happen like if you're doing the mtls thing, then that just happens you don't specify you don't describe how the mtls happens at this API level you you know like, and so that's so these back-end capabilities are describing things that happen like inside.

D

The containers that run the service not add some infrastructure at some magic infrastructure layer, and so the point of these back-end capabilities is to say: hey. If you connect to this service, you need to have these TLS details set or you know. For example, we put the websockets thing in or if you connect to this service- and you know you have websockers available on these paths or you know, or you should use this low balancing algorithm or like that's.

D

The point of this whole object is to sort of describe the what the service owner wants to have happen for the connecting to this service. Not what the service mesh wants to happen is that does that sound about right, John.

F

Yes, that does, um if you don't mind that kind of transitions to my next question, um so it feels like there's almost two different types of things that we want to describe. One is this: is these are properties at the back end like it is running on TLS it Sports HTTP, 2 and HTTP one or you know all these different things, but then there's another property, that's what should I actually send when I'm requesting you know sending requests to this back end um if they support HTTP, 2 and HTTP.

F

One right I have a choice: I could choose one or the other um if it's TLS, it's almost. It feels almost obvious like oh well. We should just encrypt it right, um but what? If the request is already encrypted? If it's an HTTP route, we probably know if it's a TCP route, we may not know right, it could be. You know, opaque PCP stream, but that's actually T loss fights and then we don't want to pre-encrypt it um so I, don't know what that looks like from an API standpoint, but I.

F

It does seem like we like. Those are actually two different concerns and we may need to address that in some ways.

D

I think your point is fair, that all of the things that we're talking about are really only useful for HTTP route right, like all the things most all sorry, not all of our things, but most of the things we're talking about here are really only useful as for HTTP right, where you've terminated the connection uh and now you're creating a new HTTP connection from your gateway implementation, you're not passing through at the TCP level, um the the stream um you're not doing only uh TLS route style, routing based on Sni, um you know you're doing this is your only your your.

D

This is a unencrypted terminated, HTTP stream, where you're um you know where now you're, trying to uh where now you're trying to um describe the properties of the that your gateway should use to create a new connection to this HTTP. So.

D

Does that make sense.

D

Like a Candace, I mean you're writing this thing. Does that describe your mind? What this, what this means to you.

E

I thought so yeah sorry.

D

I'm not intending to make this harder like I'm, just what I'm trying to do here. This is this is one of my classic exercises of, let's make sure we're all talking about the same thing, because.

E

um But you you've compared it to something that John had said, which was completely different um because he was talking about you know I think I mean not sure I understand what John was talking about either, but I think he was talking about um you know to to whom who needs to know about this um and that's a question I. That I had too, like it's an implementer's question and I'm not actually coming from an implementer's Viewpoint, so I mean when you think about it.

E

You have to you're gonna, have to pull up this back-end capabilities um at at the point where you've got traffic.

E

Excuse me for a second you've got traffic um coming in from the Gateway, and you need to figure out whether you need to encrypt it or not. But you need to know whether it's encrypted already so yeah.

B

G

Well, yeah I, you know here's one implementation, I can Envision, let's say for example, if we're running this in the cloud infrastructure like say, for example, AWS we may we're thinking about maybe just handle this under by the cloud infrastructure. So once you come into Gateway, um you know the the owner of a service decide what kind of certificate you use to authenticate a client, but once you go down through the Gateway between Gateway and back end is basically the cloud infrastructure can automatically encrypt everything coming going from Gateway to the endpoint.

G

um So that's like one flag here, the encryption note, so the the endpoint doesn't really know because the traffic is already encrypt all the way to to the back end path. That's that's one use case. I can think of so.

D

That sounds a little bit more like what John was talking about with the mesh one, where you know, if the and that's what I was trying to say before, where it seems to me like this back-end capabilities thing almost really should have like what the business they were talking about here would re-encrypt, actually really almost should be under our HTTP stanza right like so. This is a HTTP properties.

D

This is a property of when you're, making a HTTP connection to this service, only right like it's, not when you're 14, TCP packets to this service or when you're affording an already existing like an unencrypted, an already encrypted TLS stream.

D

This is only if you're trying to make a HTTP connection to this thing right like and that's when you then say: okay, the TLs details are required right, yeah, or something like that like so, and but that and again it comes down to the fact that the backing capabilities here are describing what's running inside the Pod. What does the process that's running inside? The Pod expect you to do and the process is running inside. The Pod expects to receive TLS details right and then we're saying that the Gateway that's connecting it.

D

This everything that we're talking about here is for HTTP route, not TLS route, not to be super route right, like the when none of this is intended for use with TCP route or TLS route.

G

D

That's at least my understanding.

G

Yeah one assumption that is, you know if you're talking about Mewtwo mtos, the authentication part, the assumption is, the Gateway is already has done the job authenticating, who the client are and also do the authorization to to look at the payload to see whether you can do this action, um so that's already done by the Gateway. There's really no atom benefit for the back end. To do that again, so the assumption is you the the really the benefit of uh you know, Mutual TRS between the Gateway and the client or transport layer.

G

Security is just to secure the data. um So it's not in the you know clear text, um because I think assumption is uh the back end: the Pod running application. They just received application data. They already assume the Gateway is doing the authentication authorization for on behalf of them.

D

I mean I. Think part of the part of the point of this is that we can make it. So you don't have to do that right like so that so that you can you can you can do the authorization at the Pod level? If that's what you want to do like the again like and that's I, think that's where John's uh distinction is important, that that the mtls we're talking about here is not the service mesh magic mtls, where it's injected for you by the platform right.

D

This is a this is TLS where you're doing where the service owner has generated their own search and in their pod, mounts some certs into their thing and says and presents the the running process. For the thing that says, when you are serving HTTP use these certs um and that you know that's not yeah.

A

I think it does but I think if I, if I understand the win correctly here, she's saying that I Some Cloud providers have a similar switch of just. This is Magic I'm, going to encrypt your traffic from Gateway to back end yeah, and so it's not necessarily just service mesh. That has that.

C

A

uh It could be gateway to back end.

G

A

uh And just I want it encrypt it and in that case, like I I, don't know how to communicate that. But that is a different bit of configuration than what we are exploring here or or an alternative way to say: hey I just wanted encrypted. Can you do it for me and.

A

G

So how do I describe I think it's very, very clear. The way how Hmong does it today in Ambience? So basically, when you have Galway in a pod underline is already secured.

G

You know encrypted tunnel between them or automatic encryption. Yeah.

D

Yeah, so, in my mind this this thing this, like back-end properties thing, is for people who aren't running, who don't have the infrastructure capability to automatically do encryption right? This is this is for people who are running in a cluster. um um You know it's only it's only, for you know, people who are running in a cluster that doesn't have any of the magic stuff where you need some way to be able to specify hey from my gateway to this to the back end. I want it to be encrypted. Please.

G

F

D

Mean it'd be cool.

B

D

Useful in other cases, but but that's the main case, we're trying to hit is I, don't have I, don't have cool infrastructure available that can help help me with this I got to do it all myself. How can I make this work? How can I describe it using the game? Api.

A

Yeah and I so I agree with that idea and I do want to do a time check because we we are at time here I, just uh maybe for a follow-up offline, I I think the disconnect here is that uh what happens when we have gateways that see this back-end properties and want to honor it, but can't or like can we just say some gateways can just ignore it because I don't know how to support it. uh You know that that would be I guess maybe what we need as a follow-up.

A

um Sorry, I can't sorry, Candace I know that uh we probably just went in circle. Well, we had lots of good discussion, but I don't know if it helped uh make make this any less confusing, uh but I think. Hopefully this served as a good uh reminder that this PR exists. Please take a look at it. Some good comments in chat and in discussion today. So please, uh let's continue that discussion on this PR, it's 14, 30.

A

uh orange slack or wherever is easiest for people, but uh thanks Candace for the work on this.

E

Thank you thanks. Everybody yeah, sorry to.

D

Derail the conversation again see ya, bye.