Cloud Native Computing Foundation Envoy Community, 24 Mar 2020

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: CNCF Envoy Community Meeting 2020-03-24

Description

CNCF Envoy Community Meeting 2020-03-24
https://docs.google.com/document/d/1Yc4zkV-A_cC_R3C0u6D15WQAsRSxADs8p2l8UMMa4P4/edit

The spreadsheet is at
https://docs.google.com/spreadsheets/d/1OYS9nU55ibLr4Z-io1esgKPO4FIoWsuOzKG60RxePO8/edit#gid=0

A

A Matt Marco.

A

I'm not sure if Liam is gonna take over the clanked ID issue or I should still try to take a stab at. It, definitely need to basil, so I'm Jose I think.

B

He I think he has a PR that actually fixes it. Did you see his his fix, PR I know.

A

I missed that one I just go. Take a look yeah.

B

Let me let me find it: I can drop it in the chat once it yeah one thing that would be helpful with his fix PR I'm guessing for the last few months. We've had quite a bit of regressions, so if you're able to actually run it locally- and you want to fix some of the master regressions, that would be really useful.

B

A

I can do that yeah.

B

It was really unfortunate when that broke.

B

Drop it in the.

B

Thank you. This is our first 5:00 p.m. slot time, so I'm not sure who's gonna show up for this one. Although looks like we have quite a few.

C

Pretty ladies curse.

D

But yeah yeah for some reason, zoom wasn't working I restarted enough things to get it going.

B

Looks like we got one thing on the agenda was that you Harvey is.

C

A

C

B

C

But please that's the agenda, for anyone has anything else. Anything.

B

Else I did get this really cool spreadsheet for Michael Payne, which has alright.

C

B

C

I actually edited that a little bit and yeah looks good I. Think it's a really nice contribution. I think the IT area is where I spoke with Michael about is that we would undertake repository locations or bzl with the where the dependencies are being used, and that will be. He says you just metadata, which will be used by folks who are doing these updates in future and that will obviously appear than DIF and github to let us sort of get a better picture of.

C

You know how important this dependency update is, and if we can I do like group these bumps, so that you know we can just deal with our yeah, all those big old time ones and test ones just get them out of the way we can focus on like those dependencies which are actually really interesting for envoys behavioral and security properties. Yeah did.

B

He did he make this by hand, or is this done with the script yeah.

C

I think I think you know my hand it's pretty cold out is.

B

It I mean I'm, assuming we could probably make this with a script right because, like that.

C

Once we have those annotations yeah we'll be able to build that with his friends. Could.

B

We go even further and actually for extensions. Could we break apart that repositories that bzl file and actually have the extensions, define the repositories that they need, because that would be even more explicit in terms of being able to look through and say.

A

B

And an extension uses a thing right because, like I'm looking at a bunch of these, and a lot of these I know for sure are only used by particularly.

C

Http Jason transcoder I'm using the thrift stuff so.

A

C

Yeah so like I feel that would actually be a really huge improvement to the build process if we could use the in particular condition the belts that we're not even putting down these repositories. If you haven't actually build these extensions, I think.

B

That probably works.

C

B

Right, like doesn't basil, wouldn't basil already do that. Yeah.

C

It's probably already doing that yeah yeah yeah.

B

But it just seems like it would be a little more explicit, because then we wouldn't have to keep the mapping up-to-date in that single file with what extensions, actually them, but I'm, not sure. What's possible.

C

Yeah, the thing is: if we scatter this, follow across the trick, I mean anything's put, it doesn't really matter like with tooling. We could always do this, but it'll be nice. It's not something. A single pound I would like to keep maintaining some sort of single pane of repositories, and me it easily query that yeah.

B

I think that's fine, I mean I I. Think if there's just some way that, whether it's through basil or some other script, like I, feel like through basil, we should be able to know all of the code that uses a particular target right. Like doesn't basil quarry. Do that so I mean.

D

B

C

Yeah, it's very so query could do something like that. I want again, like I, think I'm fit me with to she's a little more sophisticated, which actually includes this metadata and print things out nicely and associates them with extension and yeah I think we would ultimately need something a bit more about basil, query or basil queries a building block for whatever you would build. Oh.

B

Sure, yeah I guess I was just saying that I think whatever we should do, we should try to make it part of CI so that, for example like if a new piece of code uses like an external dependency, that we didn't know that it uses like, we should make sure that the annotations are actually up up to date like if it's done by hand. That seems very fragile I.

C

Agree I mean right now that I had is that this is a to applying a build or test and I, don't think we can. We can possibly feet and further some of that through basil magic, but it's that's probably not too fragile. Like you know, if dazzle is never going to appear, is part of the data plane, for example, and yeah rapid Grayson maze coming the data playing some of the time, maybe control playing the others, but there's relatively few external dependencies which straddle that line and I think there's ones.

C

We can maintain my hands like that aspect of tagging. I think that metadata can be done my hand, but association with extensions certainly is best done through tolling yeah.

B

This this list is actually not quite as bad as I had thought. Like I mean I I have thought that it would be worse. I'm, just like I'm just browsing through. Is this spreadsheet public? Is it I'm.

C

B

C

I mean let's check with Michael I I mean I, mean.

A

D

C

Spots, you know just courtesy to check with someone perhaps.

B

I'm, not sure I mean there's nothing in here. That's secret.

C

B

I, don't know if it's open or not so yeah.

C

So yeah so anyway, I think we can do a normal death and then another thing I would like to see sort of out of it, something as macro- learns about today, but maybe our good friends, it's a Red Hat like Kevin and some of Alcoa know about this. It's a CPE so apparently, like all software has like its own unique identify dislike CVEs I, usually identify exploits or vulnerabilities CPEs, uniquely identify products.

C

So if we could include the CPEs for external dependencies there, that would be a huge solids favor for at least us at Google and I'm. Sure other folks would love to have that information as the tag along, because it allows you to then knock back from likely a stable version and at CPE to you know known vulnerabilities and that kind of thing. Sorry.

B

What what is a CPE, it's.

C

B

C

Id identifier, which for a piece of software so like envoy, would have a CPA at.

B

A at a particular version or.

C

Cpe, the full CPE string includes version, but you can I think they're like their variants right. You can still reason about that CPA, but.

B

Like if we so is this, the reason that we eventually want to only use versions like we would say that all of our dependencies should have a CPE assigned or Warren is the Shaw and github good enough for a CPE, because that's a that's a firm version and time yeah.

C

I mean I'm, not an expert yet on the CPU rules. I just learned about this acronym today.

C

So what I think, though, is the ultimate goal, is to get the points where we can miss, not reasoning about the security, history and status of all about dependencies, and that would be a designer property again, not so important for stuff, like basilisk, but pretty important for things like NGC, b2 or cell, or any of these like dependencies that we have which play a role in the data plane and right now we're in this situation, which is my generation where we have a whole bunch of dependencies which others like yeah.

C

This is something like random repository maintained by a couple of people and there's no release process, and we just have some shar there and that doesn't really facilitate this kind of, like reasoning, I mean particularly as we scale the number of dependencies. Ideally, this is this can be done in a tool based way or through you know, standard notification mechanisms like github release, Watchers and github released. There's this kind of thing, so this is kind of where I would like us to get towards.

C

You know and I think the way we can get this maturity is, first of all, by being pretty skeptical about new external repositories which don't match this like if you're coming along with that, you know your own mixin repository library to help you out with your filter and that filter.

C

Well, you should really go and make sure that there's some sort of really release maturity and that's being practiced and I mean we could take this even further ends and ask for you know: well, you should have like a security policy and all these kinds of things, but the very least like table stakes, is being able to cut releases and have a version history and be able to reason about what happened between two two releases like to me: I, can't kind of anything more basic than that, and it's true.

C

If you just want to work on a rolling master as release candidate, you could do something like that with the right version, history and so on, but I don't think many projects really practice that either yeah. This is kind of like where I would propose. We go at least for those dependencies which are actually important to data plane. Behavior yeah.

B

I mean this sounds fantastic. I I think that anything we do here would improve the security posture. My only concern is what I put into the github issue, which is just that I want to make sure that if we specify these rules or what we expect from other projects, you know that actually makes sense and they're not just arbitrary, because it's like we can.

B

We can go to some of these people and be like we want you to cut releases, and then they just go into github and like press the button, and then they you know, and then they tell us if they cut a release and it's like it doesn't change anything.

C

Again, if all they did was cut releases and maintained a version history between them. That to me, he's already very useful in being able to start to reason about history and being able to you know and the Sirian there just puts Fluvanna in the version history I mean you know, we want them to actually have actively maintained.

B

I am I, am a hundred percent for this I just want to make sure that if we do this, we apply this across all projects and by that I mean that we have a bunch of Google projects here in Google's, used to working for master and and and like again, I mean I think this is great. But if we're gonna apply this like, we can't say that Google projects don't have to do this because they're used to going from master or something like that.

C

It's only this more than much smaller Google projects which are in that category thing is like I, don't know the Giada education or the.

D

C

Places where we've told people to go cut a separate repository because we want to put in their main envoy one and that's basically where they are and I think it would be nice. If, if we could get something a bit more sword going on there agree, then there are some major ones which I think caught squats taken action, ing, better job on with cell and others like that, and you know cell was kind of like yeah. It exists internally at Google, and then we used to side to open sausage.

C

I, don't think, there's been much in the way of process or that kind of thing had yet yeah.

B

And again, that that sounds great, like I know that for some of these dependencies without naming names, I know that some of them have been put into other repos to avoid our extensive code reviews so which, which kind of defeats the purpose of what we're trying to achieve. So, you know like we should just make sure that we write down what our expectations actually are. There.

C

Are the nice things is if we could do what you say at the beginning and start to associate and directly the extensions with Paula trees is those repositories which don't have released maturity, and we can tag that against a bit of metadata there. We can then automatically enforce that. Hey you don't get famous. You know. Are these super secure postures because it turns out, you know, you're, not practicing. You know and.

B

And there there is, there is Prior, are here like there are, you know, best practices, badges for projects and- and things like that- and this is actually I put it in the issue, but it's something that has come up in the CN CF context. What.

D

B

Bit because every project pretty much has this problem, and it's even worse in other ecosystems like C++, isn't I actually think quite as bad, just in the sense that there's fewer dependencies more software tends to be written either firm standard library. If you look at something like go, it's basically like nodejs I mean it's like these projects, pull in literally like hundreds of nested dependencies, so keeping track of that is very complicated, but there there is interest in trying to do better here.

B

So insofar as some of the security folks in the CN CF context could help here, either or with guidelines in terms of what we want to see from projects like I feel like this is stuff that doesn't apply to just us. I mean it applies to other projects.

C

Do you have like dedicated folks and seen Seattle working on this, or is this just like just apply to chat about security, No.

B

So there is something called sake: security and sense you have. There are people that focus on both the security projects and just general security posture for the CN CF ecosystem. I doubt about this issue and I was told to basically open an an issue against six security, and one of the things that we might consider doing is you or I are both of us. We can go potentially present or talk about it at a six security meeting, just to explain some of the problems that that we're having and maybe see, I mean I again.

B

I, don't know that we're gonna get anything useful out of that. But given the fact that a lot of what we're talking about is not really envoy specific, it's just dependency maturity and like dependency, tracking and things like.

A

B

It seems to me that there's a lot of common stuff here.

C

B

So let me I it's it's on my to do. I will open that issue and I'll make sure that you're tagged and then maybe we can get a meeting slot and we can at least go talk to them.

C

B

But but in terms of near-term stuff I mean I, I love the idea of getting this spreadsheet like built into some tool, that's actually checked in CI and like we can make sure that the annotations are correct on the extensions and at least then it would allow us to understand like what do we depend on? What is it used by? You can imagine that now that we have all these annotations around you know is an extension like alpha. What is the extension security posture like? Maybe we have different rules around?

B

You know what we require from from DevOps. You know it's like if they're in the core extension or they're trusted for for untrusted data, like maybe they'd, have to have a different posture, I'm I'm, not sure yeah,.

C

I, didn't that be great, so yeah, hopefully well, I, think Michaels neck next planning to take out the spreadsheet and at least add some cheering metadata and we'll see from there. What we can do so.

A

We have a nice great I, think.

C

That's all I have to say I'm that table account so yeah.

B

Cool um I, don't think I had anything else did that day. I won't have anything that they wanted to chat about.

B

Going once no anyone.

B

All right have a good evening.

C