Cloud Native Computing Foundation Service Mesh Interface, 13 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Service Mesh Interface Community Meeting 2020-05-13

Description

Service Mesh Interface Community Meeting 2020-05-13

A

Hey everyone: um this is the smi community call uh on happening on wednesday may 13th.

A

uh We are going to kick off the meeting today with community stand up and introductions if you're new to the community feel free to um after stand up, introduce yourself um and then, after that, we can just do some follow-up from the week before in any open, prs um and yeah. If you have anything again feel free to add it to the agenda, the link is in the chat.

A

Okay, um thomas. You want to kick us off.

B

Sure uh I have been answering a bunch of questions. Thank you. Everybody who's been asking them. I think they're really great michelle and I had a good conversation this morning about kind of ways. We can update the spec to explain the decisions that we've been making as time goes on. uh I think I had a couple open questions on stefan's pr that either I missed a response or didn't get answered so I'll bring that up, but other than that, I think that's it. From my perspective,.

A

Thanks, uh stefan, do you want to um share anything you have for stand up today.

C

I haven't made the pr I have made a couple of issues to discuss. First, what to do so.

D

C

We got stuck at defining the tcp route, spec.

A

Okay, cool yeah: let's discuss that uh later on this meeting for sure? Okay, that's it for me: okay uh danielle! You want to give us a stand up.

E

um So we are again we're we're also still working on figuring out the the tcp and udp route specs.

E

uh We had a quick little chat with uh with thomas this week about um some tcp route matchers, in particular by adding things like s, I matching onto tcp routes and which, in theory would open up some of the.

E

If you go along that mindset of having protocol specific matchers, it follows the pattern of having like http route, has http specific matchers. Tcp routes would have tcp specific matchers and then udp would have. I mean udp doesn't really have anything, but in some I've seen there's apparently tls over udp. So apparently you know we could. We could in theory, do something of that nature and then, as if we add more more protocols, more things to to route with, we could add it um again.

E

There was some back and forth as far as to like whether like how that would actually work for implementations, and I don't think that it would be if you're, using a sidecar implementation.

E

You don't really need to use those kind of mattress as much, but if you're, using something that doesn't use a side car those mattresses become much more important to handle again basically access and that sort of thing I think, just from um I think.

B

I was going to say I think it's even more interesting when we start thinking about this in relation with the um sig app. That's no sig networking! That's doing the ingress v2 stuff, because that's really, where, like the sni matching, makes all of the sense in the world.

E

Yeah and uh it's just one of those once we you know what, if it follows, the mindset that we've already that the project is already laid out, uh but it just sort of takes it that one step further and says: okay, we've been doing it, we just haven't acknowledged it now we can we're actually just going to move forward with it. So that's sort of where we're at right now.

A

Cool thanks: um is there an issue number or an issue? You could link us to where all that discussion is happening, or is it in the chat.

B

It is definitely an issue. Okay, cool all right, I don't remember which the issue is. Let me let me go dig around for it thanks.

A

um Michael, do you have anything for us today.

F

Nope not really for my side.

A

And eat, if you have anything yes, really: okay, cool uh anybody else want to um uh give a stand up: naveen, josh, sopduck, uh nicolet,.

A

Okay, no problem, if you do want to introduce yourself, feel free to jump.

G

A

G

I'll go ahead. I just josh burkus. I work on a lot of things. Kubernetes, um honestly. What happened was my meetings reshuffled, so I could actually attend this, so I thought I would drop in and check on. What's going on with smi.

A

Awesome welcome.

D

D

Currently, I am working on smi conformance tool, uh which is a gsoc project, so yeah I let this back and I dropped in here to know more.

A

Cool, um hey uh how's, the conformance stuff going. I remember there was like a spec. We were trying to create, but I didn't I didn't think I don't know. If there's any progress, that's being made uh there.

D

Yeah, so I was going through the spec and uh yeah. I was thinking of creating a maybe sample app and uh then, uh whenever a service mesh is deployed, this mesh uh sample app would also be deployed, and then we can drag down all the all the like all the crds and uh metrics and everything uh accordingly.

D

uh So it will be bundled in uh with the service map like in the adapters that we actually use so yeah, so uh the spec, uh the we will update the spec too.

A

Okay, cool awesome um are y'all doing that piece by piece or are you just kind of tackling the whole thing, because I'd love to see if you have like even just traffic split conformance kind of done, I'd love to see how that works.

D

Yeah so first of all, uh we will uh go with uh traffic metrics or, uh like I I'll, just look down whatever can be done uh like easily, and then we will tackle a piece by piece so because I'm just like uh getting through what uh getting to know how we can use graph on our prometheus or some other metrics to just like, uh because traffic matrix, I guess, would be the easiest to tackle.

A

Okay, um I'm in the weeds and metrics myself right now. So if you have any questions or something, I may not know the answer, but I can kind of help figure it out, because I also have been digging around. As thomas knows,.

A

um All right anybody else.

H

Yeah, uh just a quick introduction from me, so this nikolai I am with kong. I work on our service mesh called kuma and we are looking into sms pack as every other service measures do so, let's see.

F

Cool, hey, would you maybe, in one of the upcoming meetings, want to give a demo or something.

H

Oh yeah yep, I guess yeah cool.

A

That's great great to be here awesome: okay, um moving forward. uh I think um one of the things that I had kind of mentioned last week was uh like I just wanted to kind of close out on the versioning. So there is a pull request up.

A

I still need to rebase and add some things, but it's an attempt at reorganizing the uh the repo to make it a little clearer what version is attached to what and what the specs version is so up until now there hasn't been like a summer attached to like the spec itself, uh but I moved everything like it. I moved all the um like high level, spec description uh and terminologies.

A

I added a terminology section and did a few other things into like a spec file and then that thing gets versioned um and we can do like tagged releases of that.

A

um So right now I just versioned up it at like 0.4.0, I'm going to change that version to 0.4.0 working draft, and then we can once we all agree on that. If we agree on that, then you can like tag it at 0.4.0 and do a release there. So that's how I'm thinking about it.

A

If you have I've gotten positive feedback, I think the one thing that was outstanding was, um uh I think, thomas and stefan suggested that we get rid of like the api group and version api version header on all of the examples, so that we can just like iterate on the examples without having to update all the versions on the examples because, like those have gotten left behind in the past- and it's like a very tedious thing, um so you might be wondering oh, where do I get that version information from so at the top of every um api uh uh file?

A

Api description file? uh There's a header that says like what um api group and version these resources uh belong to. So that's the general gist of it. um If anybody has any big objections or any little objections, like I'm happy to take comments right now or on the.

B

Pro I I have zero objections. My only question is: how can I help to get it merged.

A

Oh cool, um I think uh I just have to do a rebase, um so let me do that and finish up some stuff later today, um but after that there will be some holes. So there's like a terminology section, that's not like filled in and stuff like that, so we could like iterate on that that'd, be really cool, that'd together, great so yeah. Let me just rebase and I'll hang out later today and we can try to get it merged.

A

Okay, um sneha is a colleague of mine. She has some questions. We have some questions around smi metrics that we posted. I talked to thomas a little bit about this earlier today, but there's an issue in the smi spec repo for that I'll link it in case anybody has a chance.

B

I just moved that over to discussions by the way yeah.

A

Discussions what's discussions.

B

It's like the coolest thing ever now. When you ask a question: it's not an issue anymore. It's a discussion, wow, it's it's gonna blow your mind. How do it's like.

A

There's a tab for it.

B

It's like discuss and uh github got together and sorted their stuff out.

A

That's super cute. I like that a lot um cool all right, so there is a discussion 165.

A

here. um So if you have any uh time today, that'd be great to or whenever to answer those questions, that'd be great um and I'm gonna try to take a stab at some of these myself.

A

Okay, um all right! That's all I have for uh discussion items. Does anybody else have something they want to discuss? Do we want to go back to the um tcp matching or actually the tcp uh spec uh issue in general staphon? Do you wanna talk about that.

C

Yeah so right now we have the tcp route in smi, but it's just for me. It's just a placeholder.

C

I don't know how others see it. There is no specification of this object.

C

So there are my mind: there are two options: either we define tcp's tcp route as a way of matching ports, which I think it makes sense, or we just deleted it from the spec and we add the type in the in the traffic rules that can be grpc. Http, http, v2, tcp, udp.

C

B

The original idea behind the tcp route was just to make it so that you could write a policy that matches not actually to define the protocol.

B

Now that I've said that, I think I love the idea of moving ports over to tcp route. I think we just need to figure out what happens to ports on the traffic access policy, because it's there today and we need to figure out what ports will mean for the http route group as well.

C

Yeah, so I think the uh the port matching can be added to all routes, no matter type. So let's say it's like an interface. Every route has to implement can implement the matching based on ports, because all protocols are are port related in a way right.

B

Is there any reason why we couldn't compose these, like if tcp route matches plus an http route group like? Would that solve the same problem, because then we won't have to duplicate the data everywhere.

E

Could you do it.

B

E

Could you do, could you do it by reference so, instead of having, instead of having a uh right instead of having duplicate records, you could just reference a port.

B

That was kind of what I was suggesting, but on the access control resource. So your access control. If you want to match routes for http on a specific port, you would reference both a tcp route with a specific port and an http route group. If you wanted to just match everything coming in for a service on those http routes, you would do that without the port, and if you only wanted to match on the port, then you would just do the tcp route and not the http routes.

C

Yeah, I think that's a great idea, but what happens with udp, so you cannot have http over udp right.

B

Right so with udp you would just have I mean we would technically need to have a udp group. So so maybe the point is not to have it be a tcp or udp, but actually to call out what we're trying to define here, which is what l5, which osi model are we going to pick on here for.

F

There is only one osi model, but um thinking a bit into the future. As far as I remember, http 3 is based in ub throws out the tcp part. So should we come up with a more generic way to go about that? Not you know, assuming that there is tcp and udp.

B

Or maybe the better question is: what value do we have actually calling out tcp versus.

C

B

Instead of just calling out that it's ports.

E

B

E

I'll I'll throw I'll throw a wrench into this discussion that came up in one of our client meetings.

E

Tcp udp is great, except when you get thrown into a commercial setting that uses neither.

E

So we have a client that manages like voip stuff and they use some ip protocol, not tcp or ip I mean it does have. It does have a source and a destination port and it does have a source and a destination ip, but it's not tcp and it's not udp and the problem they have is.

E

How do you route this.

B

I I mean I like the idea of making it an ipmatcher or at that level right, because then you could also do wild cards for ip addresses.

B

You could say this should match all ip addresses, or this should only match non-routable ip addresses, or this should route you know like it feels like that's an interesting way to add it all in, and then it's generic it's not a protocol specific. It's really what we're trying to do with it.

E

Yeah and that, but what I'm saying is, if you look at it from that perspective, then you could say: okay, we have http routes, tcp udp and then, if somebody wants to implement, you know a base ip route.

E

You know they can go ahead and do so without interfering with anybody else.

B

Well, the is there or so that's. The question is: is there anything specific that we need to know about that? The protocol at that level.

B

E

Came up with a bajillion custom, ip protocols, for you know, industrial environments like.

B

Yeah no totally, my point, though, was is: is it generic right? Do we only care about it, a source and desk port and a source and best ip? If we do then.

E

B

It's better to go.

E

That route, what the issue with that is what specifically can be routed on for that specific protocol who knows, or you know what I mean right now.

C

The same thing about tcp.

E

We we for tcp, we have a standardized sni header that we can use, but for some custom thing.

B

E

B

The sni point convinced me: we.

A

B

Want or it might be advantageous to have a generic ip, but we definitely still need the tcp, and so at least for today we might as well just do the tcp with ports and layer it and call it done. Unless someone thinks that's a horrible idea.

E

I guess the the only question uh the only question with referencing um becomes an issue with.

E

Name spacing and could be an issue with.

E

Access control, as far as, if we say okay, we're going to put right, are we going if we want to reduce the number of duplicated code by having a ref by referencing, a port as opposed to just entering the value.

E

If we want to have you know, 10 namespaces we're still going to have to create 10, you know duplicate, namespace ports and it doesn't really solve any problems per se. It just ends up being a more of a nightmare for debugging, because oops you.

C

Know I don't think.

E

C

Because traffic target is cross namespace.

B

Well, I would also like to make traffic target not cross namespace.

E

Trust I mean traffic target kent right, but that's the the issues traffic target is cross namespace, but not using referenced objects.

E

You can right, you can you can manually def, you know enter information, but it doesn't reference objects from another namespace. It does.

B

It does actually today that's the thing that.

E

B

Change because that's a big nasty security issue.

C

A traffic target can be created in a namespace and can reference a service account in another namespace and a destination.

E

But just but does it, but does it actually use the object reference or does it just have the name and namespace.

B

It's right now this is the object reference that is yeah or that's the key it was supposed to be, but.

E

That that's, the thing is: if, if you have our, if you are back restricted to one namespace, you can create a traffic target that references, something in a namespace. You don't have access to.

C

Any like network.

E

C

E

Like that, whereas if we were using actual object references, you would not be able to reference an object that you don't have visibility to.

E

Am I am I am I correct on that? That's am I correct on that assumption.

C

So, let's assume my own on ace right and I want to block access to my app in my namespace from a different namespace, so I have to reference something from another namespace I can say only the.

B

Service, it's all blocked.

B

The problem is actually the who who creates the traffic target, specifically at the moment, the traffic target. Let me make sure I'm not talking out my butt here.

B

There's one specific field on traffic target that I find frustrating, which is the destination, allows you to put in any namespace. That's the piece that needs to change. So traffic target needs to live next to the resource that it is protecting, but it should be able to reference sources and specs from any namespace.

E

But I will take you that one and go one further by default.

E

I have item in my test namespace by default. Nobody has access to my app. I have it that if I can only see my namespace, I have two choices. I can either let everybody or I can let nobody I'm, because I'm not aware of any other name spaces, and nor should I be.

E

However, if I now am granted access to namespace 2 now I can actually reference objects in there and say: okay, I will allow from you know from these right from x and y in that namespace that I can see and can actually reference directly as opposed to nothing.

B

This is, this is an unfortunate outcome of us smashing identity together with kubernetes objects, because, theoretically, if you are in the test name space and I'm in the bar name space, I should be able to say I'm coming from the bar name: space. Here's my identity and you go great I'll put it in awesome. Let's do this thing, but with the the objects I get, your point likes, discovering it and the rest of that, like I don't want you to see the service accounts in the bar name space. You don't like.

B

I just want you to know that that's the identity that you should be checking.

E

If I'm, if I'm, if I'm restricted to my name space, I don't even know you exist at all.

C

Okay, but that's not practical what you're saying like in normal use cases you have, you are allowed to a single namespace and you want to allow, for example, the ingress controller to access your app, because you need to expose it. This is how.

E

Kubernetes work, but this.

C

E

This is what, but this is what, but this is what what thomas was saying is if, if we are assuming that administrators that have cluster-wide access and know and have full visibility, if they're, the ones that are creating objects great, but if all of a sudden we're not dealing with cluster admins and we're dealing with people that are, you know, restricted to a namespace if using smi becomes much more difficult.

B

That this is actually more a question I think around the r back for the implementation, because, theoretically someone correct me if I'm not totally wrong here, even within object reference, it's really just yaml, that's going into the database. We could put anything in there anything in there that we wanted.

B

The big problem is that the implementation needs to go validate, that that exists, which means that the service mesh implementation needs to have cluster-wide access, like the user, doesn't actually need the cluster-wide access, but the service mesh implementation does.

A

That makes sense, but I understand what daniel's saying is that it's muddying the waters when you say: okay, I'm gonna reference, something out of the name space. I do want to say: okay, we're at time. um If y'all want to continue this conversation, we can stay on for another 10 minutes and continue. Otherwise we can continue offline.

B

uh Daniel would you mind creating an issue around this as well, so that we can chat about it and write our thoughts down.

E

Yeah, I need to think about it a bit more, but I think, but.

B

I think it is a discussion that we should have at the bare minimum. Getting namespace removed from the traffic target destination is the right thing to do. The question then becomes what we want to do with the other object references. Also, the port like it makes no sense to specify a single port right. uh Staphon, that's right.

C

B

Was my point, I think, let's, let's just make the change where we put move port off traffic targeted onto tcp route, like I think that makes a ton of sense. Okay,.

A

So then, anytime, you want to reference a port. You have to use the traffic. Excuse me, you have to would have to use the tcp route object right.

C

Yeah that can have many ports, not just one right on the normal choice of like we can have many ports.

A

um Hey so uh one more thing, um thomas, uh you had like a gist where um we talked about a bunch of like uh not referencing, just service account as like the source uh identity. um It was a way to decouple um us from using just like kubernetes things. uh Do you still have that information.

B

uh There was a, I moved, an issue over to a discussion: okay,.

A

Well I'll look through that, but it was just. The idea was hey: let's have uh multiple um like ways to reference uh identity, not just service account. I loved. Oh.

B

Right, let me see, let me look around, I I'm remembering what you're talking about now. I I would love to kick off that conversation too. We're going to be starting implementation on the traffic target stuff here sooner rather than later, and I think we need to do a spec rev before we get there. That's.

A

Good all right, thank you. Everyone for a very productive discussion, I'll see y'all later bye, bye. Thank you. Well,.

E