Kubernetes Secrets Store CSI Community, 7 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Secrets Store CSI Community Meeting - 2021-01-07

Description

Kubernetes bi-weekly Secrets Store CSI project meeting.

A

All right welcome everyone. It is thursday july 7th welcome to the csi secrets, community call and uh just as a reminder, uh this call is governed by the cncf code, the conduct so just be nice and kind to each other. You'll be okay.

A

We got a pretty uh decent agenda and again happy new year, everyone. Hopefully everyone had enjoyed the holidays and or time off and recharge the batteries.

A

I will go ahead and moderate if anyone wants to take notes, please feel free if you're in court reporter mode, if not I'll, try to do double duty.

B

I can't help it too much.

A

Okay, thank you finish and um if there's anyone new to the call, if they want to introduce themselves, I'm not sure.

C

Yeah, I guess I can give a quick introduction. Yeah go find.

A

C

Yeah, thank you. My name is.

C

I'm a contributor for set manager and I might work there uh at jet stack um next week, probably and I'm interested in knowing the sick oath. um Like things you do uh yeah, that's pretty much. Why I'm here awesome.

A

And I want to make sure I pronounce it is it? Is it mal or male yeah either way? I would say mile, okay, now, okay, all right! Well, thanks for joining us, uh you know we look forward to working with you on this project. Thank you all right. Let's go ahead and dive in um and uh let's see first topic here is uh credentials used uh for driver, proud jobs.

B

uh Yeah, I actually added that, after some discussion with rita and tommy, so uh last week uh we saw uh the gcp jobs were failing, so I had created the github issue, 418 to basically list out the pr's where it was failing and then tommy was able to take a look at it and found out that the credentials are expired. So now we have rotated the credentials for the gcp provider, uh but again one the other. One thing is it'll expire again in three months, so I think I just added it to the agenda.

B

So we can see what is a more sustainable manner, how we can rotate these credentials because uh even for azure, we use service principles which could potentially.

D

Expire, yeah I'll uh I'll speak to the uh google thing, but the credentials that are used in the integration testing are governed by a google policy. uh That right now is exported service account credentials. uh The max lifetime is 90 days. I think uh so.

D

um I'm looking internally to see if I can get exemptions for credentials like this, because 90 days is kind of a weird spot between uh not frequent enough to automate and but like yeah it. It is uh we're like difficult to automate, um especially since we have to uh put it into the kubernetes infra infrastructure which, like I don't have you know any permissions to that.

D

So uh right now I think it's toil for gcp and I just need to make bugs for us every 90 days to do it, but yeah, I'm not sure.

B

So do you know about the other credentials that gcp uses I mean most of the pro clusters. Have other gcp credentials right so do they also have the same limitation.

D

So on gcp there's things that are like exported credentials uh that you can, you know, take and put on your laptop or you know, put anywhere and then there's, uh like instance, metadata or you know, like uh the gce instance- will have an identity, I'm not too familiar with how the proud clusters are configured. But if we have access to the base jobs identity, I could just grant that the necessary permissions uh over the secrets for the integration test.

D

Yeah, I can look into that.

D

There may also be a way I think asher has a way to translate like gcp or other like arbitrary oauth identities, into gcp or into azure identities. uh Maybe if we can access just the base pro identity, that might be a way there to avoid exported kind of credentials or requiring secrets for these tests.

E

The um were you thinking, um like maybe just reuse like some of the other jobs that that are running like say, testing, kubernetes kubernetes, on gcp yeah. I think ben alder and and the sig test team probably would know way more about that than any one of us, so you may want to reach out to them. Tommy do you know an elder.

D

I do not, uh I can okay.

E

I'll get we can share the his um github tag, um but yeah, I I think for azure. We are. We try to use like the same identity for all the pro drops, so that when we do rotate, we only have to do it in one place and then all the drops will just get it. Yeah.

C

E

Cool, so if you do have, if like gcp, has something like that, um then potentially someone's already rotating that every 90 days, maybe um then you don't have to worry about it right, so you just have to like consume it. Cool um yeah.

D

uh So you say uh ben elder: there is one yeah.

E

Or stick testing you, you can send a message there, they're um they're, pretty active there. Okay.

D

A

A

So I think we're done with that topic um yeah this next one. This is. This is simple um this you know. I think everyone knows this has been kind of an uptick in uh meeting zoom bombs. I was actually on one uh it's pretty crazy to experience that. So uh what we're gonna do I mean from the community side, simple, we're just going to add a password to this meeting and that will kind of stop some of the bots.

A

But the big key here is uh we're going to disable the ability for anyone to just be able to share. So if you do need to share just ask the host and then they will promote you to be able to share, and then by default we are going to disable the whiteboard feature. We, I don't think we draw anything here anyway. So not a big deal there uh so just know. uh Next meeting there will be a pass uh pasco to the meeting, we'll update the doc.

A

Obviously and it'll be something like all sevens, it's something very similar, it's simple, but um that that helps a little. uh That's any questions about that. It's pretty standard stuff.

E

Okay, cool, so can can you update the zoom link at the top and I think like for me- I just normally click on that. I don't even look at it.

A

Yeah yeah so uh we'll add the the passcode here. All this, this stuff will be perfect, updated. I don't think you can do um like an inline uri with the passcode. I think you'll still have to copy and paste that when you when it asks when you enter the meeting.

A

All right, so next up uh anish talking about v.o.19 latest release, that'll support some backwards compatibility.

B

uh Yeah so before the holidays I released 0.18, so it had quite a few improvements and stability, um so I've created a small milestone, 0 0.19, which is for the next two weeks. uh But uh this particular item is for the grpc supported providers right. So we added support for grpc in 0.0.14 and right now we have four releases from that.

B

uh So the plan is a v0.19 will be the last release that supports backward compatibility with the all provider uh in working format and also having the grpc format and starting from 0.0.20 we're going to deprecate the old way of doing it, which means all providers should have a release that works with grpc changes so implementing the grpc server.

B

So I wanted to bring this up because I think right now our two out of the three providers already have the support for grpc. So I think we just have to make sure that the other provider also gets the support and there's already a work in progress pr. So hopefully we can get that merged and having it till the 0.020 release gives the provider the time to get it merged and also have all the tests updated to use the new format.

A

All right any comments or everyone's okay.

A

Okay, all right last thing on the list is, I just want to kind of just take a moment. It's a new year. I know we have our road map out here. We got some things in flight and obviously we got a backlog, but just just curious from the community.

A

Are there any kind of big ticket items that we may want to focus on for this maybe semester or the whole year.

B

Yeah, so I think, uh last year we went through the stability dot, um so it's also a little bit work in progress, because I'm looking at another link that the rita had shared and I'm going reviewing that to add more criteria that we can add for the list, but probably for the next few months.

B

I think uh what we want to do is we have a stable milestone, so we want to go through the items, pick uh issues from the stable milestone and start working on those so that we can get the driver to the stable release and the same applies to the providers as well, and I think one thing that is probably missing is security review. We probably also want to add that to the milestone, because I've had some users ask about security review so.

E

I think for that maybe we should um maybe uh let me ping one of the save off people to see what what we should do there. um I like it to see if they have a process for sub projects, let's start there and if it, depending on what kind of answer we get, we may have to also work with, like just c and cf to fund it. um But let's, let's start with sega, since it's a sig off sub project.

E

What do you guys think.

B

Yeah, it makes sense.

E

Yeah makes sense, yeah, okay, because I I think it does take some time to um get funding and and and get like vendors. So we may as well kick off sooner rather than later,.

D

Yeah, ideally, I think we would have most of the stable stuff kind of like done by that time, just so that there's not too much changing after, like after the review, um or at least not too much play into changes, but yeah. If it takes a while, then now it's probably a good time to take that off.

E

Is there something a bit more? uh Maybe can we break up these into maybe more uh attainable uh milestones like like smaller chunks? uh Are there one some of these that that are lower hanging fruits that we can do sooner rather than later? I'm just trying to organize this so that uh we can sort of have like tiny milestones before we hit the big, stable, milestone.

B

It is so the way I have it right now is all the issues in general are in stable, milestone, pool and then, as we create the next smaller milestones like when I created zero 19, I moved some of them from stable to the next milestone. So I think whenever we decide that this is something that we can get it done in the next release. So we just moved from stable to the new one and stable is basically just a pool for everything that we really want to do for stable.

E

A

Does stable, I'm sorry go ahead.

E

A

I'm just going to say, will stable will that take us to a v1 status or is that just still a minor.

B

um Are you talking about the api version in terms of the yeah.

A

E

I think you're talking about release at this project release version, not the not the apis right.

A

Yeah, okay, so when we burn down stable, where does that pull this out? I just want to make sure I'm.

E

Understanding, um I would imagine we could potentially cut a v 1.0 release.

A

E

It's a it's a good signal to the community that hey it's gone through a lot of vetting, and um you know stability, testing and and all of that.

E

So yeah, so to answer your question: yes, it's a v1 data release, not no no impact on the apis. However,.

A

All right that is the last item on the agenda: I'll open the floor. If, if there's any um anything else, anyone wants to chat about.

E

um I do want to come back to our new member on the on the call just to just to see if there's any questions or any um anything that that maybe we can help uh clarify or or is there anything that you you think we can collaborate on? It is another way to ask. I guess.

C

Yeah so yesterday we mentioned, like we said uh in one of our meetings, that we we had to go to the sequel oath group, uh but I can't remember exactly why.

C

And uh yeah, I'm sorry, I'm not really prepared. um Oh, but.

D

C

I promise next like next next time, so in two weeks I will probably have more uh like real questions. Okay,.

E

C

There is some interesting things that uh search manager would be uh interested in working on. I guess what.

E

C

E

Oh no, I just figured we uh come back to this, um but yeah. Definitely, uh you know feel free to uh discuss this at a later call. um By the way, are you on slack on the kubernetes slack? Okay, can you find you.

C

C

Wait great! Oh sorry in the csi channel.

E

uh No, the kubernetes sock, um but it's okay. I guess I can.

C

C

Okay I'll, thank you.

E

A

Awesome yeah. We always appreciate fresh eyes mail. So if you're going through some of the docs and some stuff isn't clear, yeah just throw an issue out there or let us know.

C

Thank you so much this is this feels so welcoming this is nice.

A

All right, um so that brings us to the end. Oh sorry was someone chiming in.

D

I was just gonna um ask one other thing uh previously at during the the few like vulnerabilities that we found like I threw out an idea about like what, if the driver was the one that wrote to the file system rather than the plugins uh like in expanding the grpc interface to to allow that to happen, um I'm wondering if it's worth it for me now to put like effort into writing a proposal for that.

D

Like do, that sounds like a direction we might want to go or or not, um yeah, because I can write up like you know more of a design doc on it. If we think it would help with uh help plug-ins, but if not then.

B

Yeah, I think that makes sense so that the idea that you're referring to is basically the provider fetching the contents from the external secret store and then sending it back to the driver and then the driver being the only one. That's writing to the file system right, uh correct, yes, yeah! I think that's definitely.

B

I mean I feel it's a good addition to the driver.

D

Okay, um then I'll write a more complete duck and like look more into the pros and cons of that.

E

Yeah and I think if if we do go down that route, it could minimize uh privilege on the provider side which, which is always a good thing,.

D

Yeah, I think some of the downsides is, I don't know how many secrets- uh people usually fetch at a time and like the size of those and the feasibility of kind of like passing those over the grpc thing. But.

B

So one thing is: we've been uh seeing github requests where users want to use a regular expression, so they basically want to fetch all the secrets that they have in their external secret store. So my guess is they have quite a few. I mean at least one user that I talked to on slack said they have about 100 150 secrets and they don't want to add each individual one to the array. So they just want to have a regular expression and every secret that matches on the drag x is fetched by the csi driver.

D

Interesting, do you do you know if those secrets are all like api tokens versus all like certs.

B

It's mostly just passwords actually here: okay,.

D

Okay, all right thanks I'll write up a doc on that and- um and we can discuss it more there in other use cases.

A

There all right thanks to tommy. I think that brings us to the. I guess I got one other question: uh are we okay with the cadence uh bi-weekly? Is that good, I'm seeing some head knots? Okay, just want to throw that back out there all right. So if that's the case, then uh we will see everyone uh in a couple of weeks january 21st for our next call thanks. Everyone have a good day, happy.

E

New year, bye happy.

A

E