Add a meeting Rate this page

A

Hello: everyone, thanks for joining our csi secrets, store uh community call, it's august, 8th and uh just a reminder. This call is governed by the cncf code of conduct. uh Please visit the repo to look up what the code of conduct is uh tldr just be uh respectful to each other and you'll do well.

A

We got a quick agenda, uh looks like it's growing, so we'll get through it. uh I don't think I see any new uh members joining the call so no need for intros and with that, let's just go ahead and jump into the agenda. uh First item: we have a niche. It's going to talk about the moving of the helm, charts.

B

Yeah, so this is something that we thought about when we were actually undoing the v0 or 2.0 release like today. The handshakes are in the master branch, which means when we cut a release. We merge a pr to the cherry pick. We cherry pick the prv merger to the release branch cutter tag and then we merge it to the master branch and then one idea was maybe moving all the chart packages to github pages so that the charts are always hosted in a single location there.

B

So we had this idea and then opened a github issue which is follow-up and then last week I started uh looking into renaming the default branch from master to main right and then, while going through that process, one thing we realized was with the change to main the github. The helm, chats url will also need to be updated, because today the hem chat url has mastered in the path.

B

um So what we were thinking was we anyways have to make the change, which is a breaking change, which means we have to tell users that the url is updated, go use the new url. So as part of that, we realize it's best to make the move the github pages right now and then also along with that, we can automate the generation of hem charts and publishing using like github actions right.

B

So what we did was uh we created a github pages branch and then moved all the existing packages to that, and then we also updated the help index to say make all these packages available on the new url and then we merged the pr yesterday to actually add the github actions which will um publish the head charts for us going forward when we cut a release. um So the old url is the raw.githubusercontent.com um the whole thing, but going forward it's just going to be kubernetes dot, github, dot, io, slash the repo name, slash charts!

B

I added this so that we all are aware of it. But one other question that I had was: we are going through the process to rename from master to main. So I think now would be a good time for us to also update our documentation with the new url for the charts, so that users start using that. So I just wanted to see what other folks think on the call about it like, instead of waiting for an actual release, I I I'm thinking.

B

If we can make the url change right now in the readme, then we can go ahead with the next steps for renaming master domain.

A

Yeah I mean that sounds about right. The I was just clicking on so is the page up yet does it look like it's resolving.

B

No, so that you just need to do index.yaml after that in the url, because it's not our actual page right. So if you do index.yaml after this, that is what um helm uses for the help.

A

Caching, oh okay! Sorry about that.

B

Yeah, so it's up and all the packages that we have today on our github on our helm, repo, it's all available here for use as well, so it should be exactly the same.

C

Hey a question so right now, right, like everyone has to like to upgrade, you have to know to type in the like helm, upgrade commands right um and will changing the repo. Maybe you said this already on an existing deployment like uh do we know if there's any issues like that, you know what I mean.

B

Yeah, so the helm, repo ad is a one-time process right. So you do that once and then subsequently, it's just helmet for update to get the latest packages yeah.

B

So once we change this as long as master branch is still there, if you do a upgrade, you still won't have any issues, but once the master goes away and gets renamed as main, then, when the user tries to do a helm upgrade, then it will just say that this url is not found like something went wrong, go and check and then, when they come to our readme they'll see that we have changed the url. So they just help repo update that url that they have and then when they do upgrade it.

C

Okay, yeah- and I think I was also supportive of doing this like earlier um before we mark on 1.0.

C

And then, during the release process, yeah the having the charts uh didn't, make it so there's like one or two extra prs and commits like uh which adds what about like 40 minutes or so to the release process um so yeah. I think I think it makes the get history more clear um to do something like this, but.

D

Yeah thanks.

A

All right.

B

So.

A

Once.

B

I'm sorry I was just going to say if uh all folks think it's a good idea, then we'll make the change in the readme. So uh when I say the readme phil, can you just go to our repo once I just know yeah yeah and then charge.

B

uh Scroll all the way up charge and then secret stress is head over and then scroll down a little bit there. So basically, when I say update the readme in the help repo ad, we are going to update it to the new url today or tomorrow, and once we do that we will add a note in the documentation saying the url has been updated. We will also post it on slack and then maybe also send it out to the mailing list so that we tell users that look.

B

This url has changed start using the new url for all the help packages.

C

Yeah, I think we'll also want to update the uh like. We have that upgrade dock on the in the book. um I don't know there and then it really stops.

A

Okay, should we even like include a banner with some time here? They you think the docs is enough.

B

uh So you mean a banner in the docs.

A

Yeah so.

B

Maybe.

A

On the just say, hey we've updated uh the helm, chart, location, etc. I don't know.

B

Yeah, I think somewhere, where it stands out for a while, I think maybe we can actually add a banner in the docs. I can look into that which will just show up everywhere so that as soon as the user opens it, the first thing that they see is that that's a good.

A

Idea, yeah just maybe around I don't know whatever we're saying you know, maybe part of the install steps or something like that.

B

Yeah: okay, I'll look at it.

A

All right, so we went through that and the renaming of master domain uh next up. Well, we have dane dane's going to take us through a demo of the updated sync all feature dan. Let me go ahead and elevate. You up to share your screen.

E

Awesome.

A

Okay, you should have uh controls and I'll go ahead and stop sharing and take it away. Okay, let's see here.

D

Desktop.

E

One.

E

Can you all see my abs code?

E

Yes, okay, I will try to make this quick and painless, um so I kind of altered the sinkhole option, um because what I had last time would only allow syncing all listed secrets within one opaque um secret type. So I wanted to accommodate the different secret types for kubernetes.

E

So with this first one, the bay behavior would be kind of as expected, we'd get secrets named username and password and those would be their keys so we'll go ahead and copy and paste.

E

And there we go and just to confirm the key is also password, we'll have a look at the ammo and there we go so that one's all in well, um but then one of the trickier parts was accommodating for secrets always being unique. Even if the key was the same, I didn't want to have any of the secrets over writing each other. So um this example has username in like the the root directory of the secret mount. But then I have nested secrets as well, um so we'll go ahead and apply the update.

E

And if we get the secrets, I made the name of the secret based on the path where it was mounted. So in this case with the update, um they were both mounted within a nested directory and then the secret name, and then, if we get the key again it should just be, um it should still be password. So the key doesn't change. It's just the name to keep it unique.

E

So no secrets are interfering with each other and then um again to show that you can also include um sync all with this, with an opaque secret object. So with this behavior, all of these secrets would be included under as keys and values in dv secret, so go ahead and quickly apply that update.

E

And we see db secret and we'll go ahead and look at the keys so again to accommodate for um similar naming we want to. I went ahead and made the keys based on the uh nested structure of the path so that these wouldn't interfere and um yeah. That's pretty much the the the meat of the feature.

E

um I have a couple other examples here, we'll just go through the tls example, so I'm mounting two certificates and then, if we just look at one of them, um we could see like the key and the both the keys have the required um values for tls, so tls.insert tls.key, the user would only have to refer to them as tls secrets. They wouldn't have to actually worry about creating these keys and that behavior is the same for ssh and basic auth.

D

As well and the doctor can think jason.

B

So our question here writes in this tls example: you have cert 1, insert 2.. uh How is the driver I mean? Is the driver passing the cert and the key file from that cert one file?

B

Are we still using these deterministic file names? That will tell us that this is a certain. This is a key.

E

um There was that um yeah you, you brought up that the driver uh was smart enough to distinguish between the key and the certificate, um so I I just utilized that same behavior, that's already there. So I'm pretty sure when I'm mounting these the certificate and the key are within the same file.

B

Okay, uh but in this also, this example has served one answer too right, so in the dls secret, which one is being added.

D

Oh.

E

It spells it.

B

Out.

E

Oh.

B

Got it? Oh, it creates a secret for each one.

E

Yes,.

B

Okay,.

C

Yeah, I think that behavior was a little bit difficult for me to follow of like when is it doing multiple keys within one secret versus? When is it splitting out into two secrets um but uh yeah? I guess I'll look more at the the pr on that um to kind of try to understand that yeah.

E

Yeah, this is what the certificate will look like, so it has the key and the the certificate within the same file, and then I was just using existing functions within the driver that split these up.

E

um So I think it was tricky to think of how to like mount just the certificate as a file and just the key as a file, and also accommodate like the fact that a tls secret in kubernetes needs both of those keys, um tls.cert and tls.key.

E

I thought this existing behavior made it a little easier to accommodate.

E

For the fact that we needed those keys in the in the secret.

C

Could you open the sinkhole opaque? um I think that was your first secret provider class.

C

And I'm sorry did this, this yeah yeah here I see the sinkhole true, but this synced to two separate secrets, not one secret, is that right, that's correct!.

C

And then, when, where was the other one this one, maybe the update yeah.

C

This one did all of those paths to the same secret right. Yes, how do what was the uh what's controlling that difference?.

C

Do you know what I mean.

E

Yeah, um so if sync options, dot sync all is true, then it'll sync each listed secret as an individual secret. So it would just be one key value pair.

E

But if you do sync, all, if you do secret objects, add an index dot sink. All is true. Then it'll, sync, every mountain secret to the to the listed secret.

C

One, oh, okay, sorry can you go back to the the previous game just for a second. I just want to see the difference there.

C

Okay, so here it doesn't define a was it a sync.

D

The secret options objects in this one.

C

Okay,.

E

Yeah.

F

That I didn't have like a couple of questions like that. Can you go to that other file like saying call the one on the right, yeah correct, so.

F

Is this secret object? Okay, first of all, is this like a secret project class like can you scroll up like it is a secret product like the one that, oh I mean.

E

um I'm trying to remember if I.

F

Okay,.

E

Yeah, it is a secret writer class.

F

Okay, so the secret objects we have is like uh the key that we are using right now as well. Correct.

E

Yes, this is already there.

F

Okay, cool, uh so that's fine. The the other question that I have is so like. If we have defined secret objects and if we have this thing called equals to true, then we are going to create multiple keys within that single secret called db secret, and in that case, when we have this uh similar uh uh keys like username, we are appending or we are creating the keys with the path right. So in that case it will be username and then hyphen.

F

How does the pod will uh refer it like do or when I refer in the port? Should I be expected uh of this change or of this? uh What we can say pattern that it will be uh sync like this, and hence my part should refer it like this. Is that the expectation.

E

Let let me uh quickly like bring those particular secrets up and um I might need some clarification on your on your question, but maybe I would help if I went into the pod so like here, because we have.

E

We have sync all is true under sync options and we have some nested structures. So we have username and password in here, and we also have those in nested.

E

So those secret names um should all it was just a way to accommodate the um uniqueness of the secret name, so um so that we could get all four secrets in here.

F

Get it so, I think mount is fine, so like mount, we will mount it in in the directory, or I mean whatever the name that we have uh given over here.

F

What I am was uh thinking here is, since we are syncing this as a kubernetes secret, probably user will be using that uh either as an environment variable or directly as a kubernetes secret right. So if they are not referring the amount and if they are referring either kubernetes secrets or and or from the environment variable then do they know that they have to be, or they will be of this name or the key will be of this name like next username.

E

Yeah, I think so um like down here as an environment. Variable I'm referencing it as.

B

That.

E

That changed name, and I think for a user to like predict that they would just have to understand how to use the feature, um because one of the things with the like singing all of them is instead of listing them out individually. Is that you lose the freedom to choose the name of each secret.

F

Right.

E

Right.

F

Okay, so I think yeah- and this is what I was sort of expecting, so we should have some sort of examples and documentation- probably around this, because new user might not- uh I mean unless they go through the implementation, they wouldn't know like what the name final name would be or what they can provide over there you're right.

E

I agree cool.

F

Yeah, that's it from me thanks really good demo.

E

Thank you, yeah awesome.

B

Yeah thanks dan.

A

Thank you.

A

uh We got one item left on the left. That's you and we're looking at a pr here right right.

F

Like.

A

I have it over.

F

Here the.

A

Implement provided.

F

uh If you can go, uh I mean you can scroll all the way down. If there is a comment on the pr. So uh let me give a like quick context, so we wanted to implement like a into in uh it. We provide or the mock provider. So we don't have to run our test against each individual crowd providers uh provider and that way we can be quick and more consistent in our end-to-end testing and whatnot.

F

uh There were like couple different options as to how to do it, so one was to just return a static secret uh values or secrets, and uh we don't have to rely on any of the uh any of the custom logic per se. uh There was one uh there is an issue related to this implementation, which talks about having uh kubernetes secret.

F

uh I mean kubernetes secrets as like a pseudo store or sudo keyword, so that uh we actually create those secrets over there and when the mock provider is uh being called mock, provider will talk to kubernetes apis or, like the security case, get the secrets and then return those uh fake secrets per se.

F

uh So the uh what we want to understand is like so one of the point that anis brought here is: uh we will still having.

F

If we go with the kubernetes secret route uh to implement this or to get this uh mock secrets, uh then we still be having dependency on the kubernetes api server and uh that I don't know like if, for example like, if api server is down, our mock uh or e2e provider will not be able to return anything so, uh and so so the best practice, probably or the best uh way to do that probably to is just uh return.

F

The uh uh the the hardcoded value or the static value as a secret, rather than relying on uh in any kind of a secret provider. So just want to understand like what everybody thinks could be. You know the good approach to do that and uh both works by the way like uh initially I had it with the static values uh like I was not using any provider and the only problem there was is like how to handle or how to test the rotation.

F

So, like sort of uh brainstorming yesterday with anish and we'll try to implement that and we'll figure it out, but then I checked the issue and which talked about this uh kubernetes. As a I mean, given the secrets as like a pseudo vault kind of thing, so I updated the implementation to that.

F

So yeah both works, so I just want to get. The community's idea is to what you all think should be the good approach.

C

I think I'll need to look at the the pmr. I haven't gotten the chance to look at it yet, but that we, I don't think for this provider we want to.

C

I don't think we would want to mention any implementation uh like. I don't think we would want a fake fault or like a fake or gcp or something.

C

Yeah so since it is just like a fake provider, I don't think we care about the security really yeah so um yeah, I think even just like raw secret values and secret provider classes- or um you know, I think, would be fine. uh Kubernetes secrets, I think, are a little bit different. um That might be more okay to to reference in the implementation, but it might also add more complexity and uh yeah. I think keeping it as simple as possible.

F

Yeah the way.

B

Sorry.

F

Yeah, I mean sorry uh the way that this currently implemented is so like. If you see right here like it says the populate world, so what it does basically is. It goes ahead and create a bunch of kubernetes secrets, and then we actually get the mount request in the fake provider. It will just do uh the kubernetes api calls for secrets and just get those exact cigarettes.

F

So that's the additional part so like it's just implemented, uh which is backed by the kubernetes secrets, for example. So if we have to cut this out, we don't have to do all these things so like within. Within that same mount function, we can just return like hardcoded values so like this is the secret and we have just returned it and then for rotation. We will uh we'll figure it out how to implement the rotation, because for rotation we'll have to externally.

F

First uh change the value of secret and say that, like it's rotated and then our provider will go again and try to fetch it uh and uh will then get the updated value. So we will figure that part out should not be that difficult.

B

Yeah, I think, like the reason that I added that comment was if we trim it down and then make it just static values, then we never have to debug provided just to provide context on the comment.

B

So it's we just need to test the driver logic and we need something on the other end, giving us a grpc response with files in it, and it can be anything and with this it's just a lot simpler, where it's a deterministic value so like we can always check on the driver that this is the value from the e2e provider and then for rotation again, like I think we discussed. So we can do that.

B

Okay,.

C

Yeah, a number of like test frameworks right have like a return x value uh and then return like y value, so like we could.

C

uh I don't think we should get too fancy with like a language for returning like for the rotation flow, but um we could do something or, like the secret provider class, tells it to like um first request do x and on the second, do why.

B

Yeah, I think one thing is: the driver actually sends the pod name and name space today to the provider. So one idea that we had was just have a map internally and then the first time the request comes in add the pod name, name space to the map and then return the first value x and then the next time when it comes. If it's in the map just return y, if it's not then written x, then add them up.

C

Okay: okay, less code is always better. In my opinion,.

F

Sure, okay, cool so yeah, I mean, if all agrees, I'll revert back to the static values and update the pr accordingly.

A

All right thanks.

B

I'm going to quote tommy on the notes.

F

Yes, that was really good.

A

All right that takes us uh to the end of our agenda today, any other uh comments or any other topics. Anyone wishes to bring up before we end the call.

A

Okay, silence is not.

B

uh Sorry so yeah so yeah, I was just going to say we had the we owed our 2.0 release uh last week following the release schedule that we have uh and then the v 1.0 is planned for september, mid mid september.

B

um So if there are any issues that you think should be part of v, 1.0 blocker like please feel free to open a github issue and then we can get it added to the stable milestone, but in terms of us as a community. That's what we're going to be working for in the next couple of weeks to get the 1.0 release out.

B

All right.

A

Yeah thanks for that, okay, all right that looks like that's gonna, be it for us today. uh Next uh meeting will be uh september september, 2nd actually in next couple weeks, uh I'll get the recording out, uh asap and I'll, also post it to the slack channel as well for the community.

A

Okay, thank you. Everyone for joining have a good rest of your day and we'll see you on the next call.
youtube image
From YouTube: Secrets Store CSI Community Meeting - 2021-08-19

Description

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