VMware Pinniped Community Meeting, 17 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped Community Meeting - June 17, 2021

Description

Pinniped Community Meeting - June 17, 2021
We meet every 1st and 3rd Thursday at 9am PT. We'd love for you to join us live!

This week the team discussed the design doc for remote OIDC login support, AD support, and design for non-interactive LDAP logins. Full notes and details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?view#June-17-2021

A

Hi everyone welcome to this week's edition of the pinniped community meeting. Today's date is june, 17 2021 just a reminder to please read and abide by our code of conduct when attending these meetings.

A

You can find these recordings of these meetings on uh our youtube. Playlist, we record everyone, and so, if you aren't able to attend these in person, you could catch up on youtube, but we would love for you to join us at our. Our community meetings are offered every first and third thursday of the month at 9 a.m.

A

Pacific time when you do attend, we ask that you put your name and any organization that you're representing so that uh we can keep track of who, from um outside, of the maintainers are joining and who from the community is joining, and we can keep the lines of communication open and just um you know, make sure we're able to engage with you after the meeting and.

A

We just have one announcement to discuss: uh we released just a little bit of a bug fix for uh 0.9, and this is a second um bug or um other things that were added to that particular lease matt. Did you wanna or anybody else want to go over this particular item.

B

Yeah um this this was sort of a security hardening fix, so there doesn't fix any known vulnerabilities. We don't know of any vulnerabilities in peniped right now, but it uh hardens the code against some potential future vulnerabilities that we speculated could exist.

B

If there's things that we don't understand, so um the way that the impersonation proxy works is it authenticates, the user it connects to it, and then it passes the request upstream to the kubernetes api and it sets some headers and so that any kind of bug again we don't know about these kind of bugs, but any kind of bug that uh you know would uh cause those headers to be missing from their requests. You know, basically, we want to mitigate the scenarios. So a couple things we did.

B

One thing we did is that the the proxy itself now does kubernetes authorization check on every request. Previously it only did that on a subset of requests related to nested impersonation authors authorizes every request, which means, even if we totally mess up the backend part of the proxy.

B

um You still can't make requests that you aren't authorized to make. So that's good.

B

um We also now, when we do the upstream impersonation, we do it as a privilege, a service account that doesn't have any other privileges, so it can only it can only do impersonation uh can't directly do anything else on the cluster and then we also added code to detect when the underlying cluster has anonymous, auth disabled, so the common one. That's that we found is aks, but any cluster that has a kubernetes api flag turned to disable anonymous auth.

B

We also now reflect that behavior at the proxy, so we refuse any request. That's not authenticated, so those are hardening stuff. Think some mo for helping put all this together. We we had a we have. We have some more items that we we may tackle later, but these were sort of the highest highest value. um Quickest wins. We could find.

A

Oh cool thanks matt, uh so on to project road up items. For june we have the remote oidc login support. Anybody want to go over this yeah.

B

This is my thing again too. um We talked some about this, but I don't think we talked about it at the community meeting. Yet uh this is work. That's in progress. Now I've been working on this this week.

B

I did a sort of a proof of concept last week based on this approach, that the problem we're solving here is, if you want to use the peniben cli, so you want to like run coop ctl against the pinniped cluster, but you want to run that command on a machine that doesn't have a web browser which is tricky because logging into your oidc provider requires a web browser.

B

So the scenario here is that you have one machine: it's like a jump post or an ssh jump jump box where you're running the cli and you have another machine.

B

Maybe on your your desktop, where you have a browser, and so we want to make that scenario work and we had previously uh previously, we had maybe overstepped our user experience story, user story here and said: oh we're going to implement device code flow, which is one technical approach to solving this, and this is another approach that we think is simpler and easier to easier to implement in in pinniped, equally secure and actually equally good user experience um roughly so um I don't know if it's worth going through all this right now to folks.

B

Yes, no andrew, I think I think you haven't heard this yet might be good validation for you, good good validation from you.

B

Okay, um the the basic the basic trick is we're going to use this standard standard part of oidc called response mode, and so this is a parameter that the client sets when it's starting an authorization request, and normally you would specify, like response type equals code, which means at the end of the flow. I want to get an authorization code back.

B

Authorization mode is talking about how you want to receive the response, so the normal normal response mode is query, which means you want to be.

B

You want the the issuer to issue a redirect and put the response parameters into into the url query. Parameters. You'll get in that way. The forum post mode here means at the end of the login.

B

The issuer renders an html form with the authorization code and the state and things like that and then posts it to your your domain, your callback um anyway, that's boring, that's kind of kind of standard of watch behavior and it's well supported and fast sites, which would be it's really easy for us to use it um yep and it's in phosphate and then the the trick here.

B

This is the only thing that we're kind of doing that's a little extra beyond the spec is to take that html form that's rendered at the end and have it um have. It have two two cases, one case where the form post succeeds automatically, which gets you basically the current behavior in in most cases. So if you're running the cli on the same machine as your web browser it'll, just post, the results and you'll see the success message and you're done logging in.

B

But if that post fails, you can fall back to showing a screen that contains the auth code to copy paste, and then the cli can wait for that code to be copy pasted and you can sort of finish the login out of band anyway. This is what I'm working on. If anybody has comments, it's not too late to change, of course, um but I think this is still looking good. So far,.

B

C

Questions comments sounds cool.

A

A

The other item, uh a d support.

D

uh I guess I can take this one, uh so with version 0.90, we released generic ldap support.

D

The intention here is to create specific, uh active directory support um by validating that it works against active directory kind of having an active directory test environment set up and uh creating a different uh identity provider object with defaults and configuration. That makes sense specifically for active directory.

D

Yes, the update here is, I have been working on trying to get an active directory test environment set up and it's been difficult.

D

I might pull someone in today to talk through things.

D

A

Does anybody have anything else to say that particular item.

B

Thanks for uh taking that one margaret, we all we all knew this was gonna, be hard and um so not surprised that it's hard, but I'm glad that you're making progress.

A

Okay uh on to an item that I pulled from the june 3rd meeting that we discussed so I was just wondering if there's anything further.

B

I don't think so. uh We decided to bring this into the backlog. I'm gonna work on it, for I think the next release and um yeah we'll have uh you know this would be a small change. I think we'll probably support this in parallel with also offering plain ammo to download. If that's what you still want, so you could still use kubectl to install as we've as we've made the project more complex, it's getting harder and harder to install it with like a single coupe ctl command.

B

um So we have a bug, that's open right now as well. That's uh has to do with the fact that we have a single yaml, manifest where we define a crd, so we define the credential issuer crd and then, at the end of that yaml we have an instance of that crd custom resource. That's the initial credential issuer and uh cap handles that just fine, I believe, helm handles that just fine coup ctl doesn't, and so you can make it work, but you sort of have to hack around.

B

You have to run the command twice or you have to split the yaml up um anyway. It's kind of annoying what it points to is like uh it would be nice if you had a nice suite of tools for managing all these configurations, like the carvel suite, so we'll probably start to switch to referencing the carvel tools as our default installation method on the website, but probably still offer the ammo with some caveats. As a fallback.

C

Just to close the loop about a previous conversation about this image package feature the vmware project that was looking to consume a pinniped image package bundle actually rolled their own, so yeah just to close the loop. That's.

B

Fine, I think, there's lots of reasons for us to do this. I mean um it provides security and usability.

C

B

And it's um you know useful to people who are invested in the rest of the carvel suite. So you could. You could install pendant head with cap controller, for example, really easily things like that, um and even though, uh even though your package might be different from our package upstream, if we're building them with the same tools, it should be, we should be able to catch things right away. If there's, if there's any issues.

B

Yeah, that is a good note, though. Actually what that, what that means for me is. We may probably wouldn't block our next release on this. This work, if it turns out if it turns out to be like a time crunch at all, we might slip this.

A

Okay, anything else on that particular item.

A

Nope, okay, on to discussion topics, uh if there is anything else that uh folks want to discuss, um while we're touching on this next point, please feel free to add that in below in the discussion topic section for now we're going to.

B

Design for non-iterative.

A

B

Yeah sorry, I always end up talking too much. um We've had this issue open for a little while and it has a proposal for kind of the. What the future should look like um here in the in the issue- and we talked about this last week as a team and we weren't confident that this is exactly what we wanted to build. So I thought we could take a few minutes to discuss what we want to build.

B

So the goal, the goal. Actual goal of this feature, stepping back a little bit from what's in the dock right now, is that if I have a active ldap based identity provider and I've got it peniped all configured against it, and then I have a client. That's like a ci cd job like a jenkins job, for example, that wants to run a coupe ctl command to do a deploy. This would be a pretty common scenario.

B

We want to have a way to give that job. An ldap service account it's like username and password in the ldap, and let that be wired into the pinup head command, with no interaction, no user interaction. So right now what would happen is you your job would try to run the coop cdl command. It would exec our cli and then we would show username password, prompt and jenkins can't type a username and password prompt. So you would just block and it wouldn't work.

B

So the specific design here that we maybe didn't all agree on is to pass the username and password through as environment variables, but to keep the names of those environment variables out of our out of our spec sort of out of our api, our cli contract.

B

By letting you specify what the names of the variables are and then those would get into the uh config, and then you, your cli at runtime, would try to read those variable names that you specified.

B

um I think some other alternatives, maybe just to open up the discussion and then I'm gonna mute is. uh We could just pick specific variables, so we could say like pinpoint username pendiped, password or pen, pet ldap, username penpadl.password, or we could not use environment variables at all and specify a file with credentials which is a little less convenient, but maybe has some security benefits, because environment variables are well passing environment variables through command lines, and then shells can be can be tricky in some cases anyway.

B

Does anyone else have ideas or.

B

E

Okay, I was gonna, make one comment: yeah go ahead, um so I'm trying to think of the case where uh so the getcubeconfig command is probably going to be run by your ip admin and then the cube configs are going to be handed to end users right and, let's, let's presume, to have an ldap idp configured all right.

E

The end user is going to want probably automate this if they can right or or something right like you can imagine some float where they're like yeah. I just don't feel like typing my username and password. I'm like this is my little box. I just want to work, um so it would be weird for the I.t admin to pick the environment variables for them, but they could, I suppose, that's I guess a valid, very valid thing to do.

E

But let's say the ik admin didn't do that and so now their cube config is set up to prompt them right. I don't really expect users to like know how to change these flags, because, like the the the pin pet cli is effectively opaque to them, they should hopefully not even know it exists other than the fact that at some point they were told to install it or, in the really nice case, the it admin just pushed it to their box, using the agents that are probably installed on their laptop right.

E

So, like the case, I could see this falling apart. Is the user doesn't really know that they're using pinniped and it's going to prompt them, which will make it very hard for them to automate scripts? And if it's a set of cli flags that tell you which environment variables to set?

E

That then requires you to modify that you can fake, which requires you to understand it um right. You could also.

B

So once you so, we normally operate under the assumption that the person who runs the git coop config command is like a cluster admin, but actually even as a regular user.

B

Once you have your initial good config, even if it's a piniped, coupe config, uh I forget what default our back we set up, but I think most users do have permission to run, get coop config again. So you could, you could say, like. Oh, I gave you a user coupe config, but if I'm trying to set up a jenkins job, I could say: okay, re-run, the git config command to generate uh jenkins coupe config.

B

I'm not sure that that's a little error prone, because you're asking a user to understand that cli command. Now they didn't need to before.

E

I I thought we required it to be able to read like credential issuers and maybe idps also remember. I.

B

Think it's just just credential issuer, but I don't know I don't remember if we set up any our back for that.

E

No, we don't set up any report. Okay, maybe.

F

That doesn't work uh one one thing that comes to mind based on most comment was uh we one option would be to to do exactly as you wrote in this github issue, but to have the getcubeconfig command by default. Always set these these two flags with some good default environment variable names.

F

So that way like maybe the defaults are piniped username, something something so that way. If the administrator wants to override them, when they're running get good config they can, but if they don't, then the end user still has some environment variable names that they can set without having to edit their config.

E

It's not a bad idea. I think I think moyer had pointed out a concern in that flow which was um or sort of relate to that flow is by making you opt in to the value of the environment variables like if you don't set like, if you don't have the and like, if you don't specify which nmrs to use there's no way for like, like the I guess, eli to try to consume something. It's not supposed to like, like you effectively have to like very hard opt-in to this functionality.

E

So like we're not trying to force you into a particular path, I don't know necessarily if that matters like it's really hard to do like post-level security, stuff right, like all the stuff that you're normally executing, is running as your user can like read your entire home directory. So it's like go to read your credentials off the disk if it really wanted to like it doesn't have to like wait for you to type your password in there's. Also.

B

Another, uh so I'm also attracted to the category of things where you you pass these things in as file paths, because it's like it's the most secure thing.

B

um It is annoying to use because you have to make those files, but actually there's also a work around there's a there's a trick and if you're, using like a modern shell, a bash or whatever you can use uh for what is called.

B

A redirect so basically process substitution. I think process.

E

B

Basically, take run a command, the output of which becomes a file descriptor that you can redirect to standard in um or to it, to a file name basically, anyway, that that trick is interesting, because even then, if you use even if the command that you specify is literally like cat, this file name um or sorry, if it's so even if the commander uses echo, this environment variable looks like it would show up in your process table, but echo and all that stuff is all just shell built-ins, so it actually isn't in your process table.

B

I don't know that that's a trick. Basically, if you build the file thing, you can also use it as an environment. Variable thing with this trick and it's just equally secure and it's more secure than um or can be more secure than passing environment variables. Indirectly.

B

F

Dude, do I remember right that, with with those file tricks, you have to make sure that you have your default permissions mask set up correctly, or else you can accidentally create world-readable files that have your credentials in them. That's true, yeah.

F

um That's a little tricky, at least with environment variables. They only live in the proctofile system, which is pretty well protected.

B

Yeah the trick so environment variables, like the actual environment for each process, is pretty well protected. On, like every modern machine, um you have to be root. To read that the thing that's not protected is the process list like if I take you know, ps, aux or whatever, and I list out running processes and see the command lines. Those are not always protected across user boundaries.

B

So if you run a shell command that has the the secret in it, it might show up in process table that way. I don't know yeah.

B

We can't we can't. So we can't like stop anybody from ever doing any insecure thing. I just want to make sure that, like we're setting people up to succeed, um one other one other thought I had about this is I wonder if it's a mistake for us to use the word ldap in this cli flag, because right now the only kind of username password logins we support are ldap logins, but we're about to add ad support. I don't know if we'll we'll use the word ade.

B

We also might support client credentials grants against um odc providers, in which case you would have like a client id and client secret that are like a username and password, and I want I might want to use an oidc service account an adc client as a surface account in jenkins.

B

Anyway, I wonder. Maybe if we could pick different names, then then ones that use ldap or maybe not.

E

I would personally lean towards username and password, or something like not including the word ldap, for the simple case of we're about to add active directory at some point in the near future, and I wouldn't want to add two more flags that just simply exist to distinguish between ldap and 80. Even though there's no conceptual difference.

E

Client id and client secret are a little bit fuzzier um and like I'd, also thought about like if it would be possible for like if we had like github support in the future, if it would be possible for us to like use like some kind of personal access, token based flow. So that way you could theoretically do github login without a browser as well.

E

um I guess in that case I don't know what the username would be, because it's just a token um and the token is not really a password. It's an access. Token.

E

I guess in that, in that case I could see us just adding a new flag to distinguish between username and password, which are supposed to be supplied together, both not empty and then token, which is supposed to be supplied by itself and not the username and password.

B

Yeah, okay, I think do folks. Do we feel like we have consensus that we don't want to use the word ldap. Maybe just use username password.

D

Okay, good, okay,.

B

All right well, I can consider that, like at least one change here, I I am also maybe leaning now towards let's just pick a variable name and use that we can always add files like file path, support. Later too, we don't have to it can coexist with this. um But let's just pick a name. That's like peniped underscore username pin a pet underscore password. I mean we're lucky that we have a project name, that's very unique, there's not that many other things called pen and pad. So I don't think that's going to conflict.

E

uh Let's see I see andrew and ben are on the call: do you guys see this being a problem for downstream consumers.

C

I can't really come up with a good answer right now, so no.

E

Like the thought I had in my head is no matter what environment variables we choose if like, if you're like, embedding the pinniped binary or using the code, there's no reason you can't do like translation and like like fake those variables using other inputs, like maybe files or other environment variables or whatever.

B

Yeah, in fact, we we have another story: open, that's about refactoring our client to be a more usable as a as a go library, um and that that basically, the hard, the the actual name that we're hard coding here might be on the cli side of that api so like it might be literally part of just what the pinniped cli does and if you repackage the client into another binary, you choose a different name. If you want.

C

Make sense yeah? What about the didn't? Y'all have a pinniped, debug environment variable that toggled some debug output.

B

Yeah, we could do the same thing with that. um Potentially I think I think it's also. One of those things I think is the variable name is like red in the in the main.go and the cli, and then it sets uh some flag into the the rest of the client. I think.

C

Yeah, that sounds familiar, that I think that pattern would vibe with what we would want to do with it.

B

um We should uh almost gonna make a note here. We should uh consider this story.

B

The documentation like we should have like a little section in our ldap docs about how you could use this with with jenkins.

F

D

Cool one other thought I had is like: we have to be careful about caching like if you, if you unset the environment, variables and then read another youtube command.

D

I think I would expect to have to log in again.

E

Yeah, I think margaret is right. I think uh what this boils down at the code level is, I think, moyer wrote this code where the there's like a concept of a cache key, and these would need to be considered in that. So that way, when you do the lookup in the cache, if these are different, you get a different key and you don't hit the cache threads.

B

Yeah, that's interesting, though, because the input here is secret and it's a low, potentially low, entropy password secret.

B

So the way that cache key works right now is just a plain shot: 256 hash, that's very fast, um and this the thing that it's hashing over doesn't have a lot of entropy other than your password, so it may not be. We may want to find a safer way to compute the cache key like with the with a password hash.

B

To think I'll tell you more about this. That's a really good point marker. um We need to think about it.

F

That's an interesting it's an interesting thought. I'm not I'm not sure. If I completely follow that, um like my username and password is something that I present interactively once and then I don't present it again because it's all my resulting tokens are cached.

F

So wouldn't you think of the environment variable in a similar way, like I present the environment variable once my resulting tokens get cached and then I'm not presenting the environment variable again I could, or I could not it doesn't matter like you can have environment variables, set that aren't read by any system and that's okay and you can also unset them and if no system tries to read them, that's! Okay!

F

Until the next time the system tries to read them that it's an error, it's kind of a normal way. I think about environment variables.

B

Yeah, I guess that what that points out is our caching is making some assumptions about the interactive login case right now that like, if I, if I run a command and it tries to log into a particular cluster using ldap I want to, and then I do the same thing again.

B

I always want to reuse that cache. If it's available, I don't want to like ask the user hey. Do you still want to log in as that user again like that username? So maybe in this case we could either just completely ignore it, or maybe we could just cache cache based on the username header, so the username environment variable not the password. So if you logged in once with one username and then you logged in a second time with a different username that would correctly like this.

B

So the bug that we'd want to avoid is I set the username to you know jenkins. I run a command, then I set the user, the username environment variable to moyer and I run another command thinking it's going to happen as me, but actually it runs as jenkins because the pet cli incorrectly reuses the cash.

F

Oh, I see what you mean. I misunderstood margaret's comment now. I understand.

E

I think just a little funny because we now have sorry like we have cli flags and environment variables that direct the behavior of the binary in a particular way.

E

um Whereas previously, I think we just mostly lied on cli flags like you could say that the prompting of ldap and username was like hidden like it wasn't stored anywhere. It was just like we typed it into a buffer and, like nothing, really recorded the ins that occurring now. We got this weird state where we, I think what moyer said, is a scenario we want to be careful of, because I think we've all been standing beside a person or known of a person.

E

That's deleted the production environment because they thought they were deleting a dev environment. uh I think this was in that same.

B

Vein, I I think we could have sorry, marco you, you were saying something I.

D

Was just saying this, just kind of seems like a broader log out, behavior kind of.

F

Yeah, this problem really makes me think we need a logout command. I think we should prioritize that.

B

I think we get around the the scenario I mentioned we get around if we just include the username in the cache key, so we do something similar for the the static token login flow, uh which is that we include the static tokens value as part of your cache key.

B

So if you change the token, so I change from like the jenkins token, to a moyer token, um like I can, I can one other use case is like I've got two terminal windows open one where I'm interacting with the system as as jenkins and another we're interacting with it. As me, um we just want to make sure that those correctly share the cache anyway. I think we get around this by just hashing the username.

B

We don't have any of the problems that are related to like a password, because, basically with the property that we know is, if you have a username, let's say jenkins and I changed my password. I changed the password that could cause my login to fail or succeed, but it's really unlikely to log me in as a different user based on which password I choose right.

B

My intention is to log in as jenkins I express that by setting the username, I'm not gonna like magically be logged in as me, because I type in the magic password at least not on any ldap server, that we that we know of.

B

Sorry that it's confusing, but I took a bunch of notes in the in the in the main document here um I can take on rewriting this issue and we can have a new design to work on next week.

B

And if anybody has more thoughts, we can continue to discuss now where we can uh discuss in the issue.

F

To uh to marco's earlier point, do we have a logout story in the icebox somewhere that I think we do? That's.

E

Something we've.

F

Talked about several times yeah, I don't think we've ever prioritized. It.

B

Yeah, that's a good point. There's log out the logout behavior, meaning just like delete your cached sessions completely. I also think we need to worry about.

B

Having multiple concurrent sessions and like it's like, maybe a different different terminal windows on the same machine should also work correctly. So I think we want to what we want to avoid is having a command that you run in one terminal affect an environment in a negative way that you're running in another terminal right like there shouldn't we shouldn't, be commands that assume a single shared global current current user session as much as possible.

B

I think we have that right now with ldap and I'm not sure we want it, I'm not sure how to get around that or if we need to support, maybe like multiple session cache profiles or something like that, it's a logout is one one factor of that one one element of that, but uh think there might be other commands in that same category, that we want to think about at the same time like switching switch user or uh things like that. I don't know I I not that happy with, like the kubernetes style.

E

I was about to mention that, like even after five years of working on cube, I still find the cube config context, command and config commands very hard to understand, because I can never tell what they do.

B

Yeah, oh so, let's, uh let's open an issue about log out and maybe we can just do log out. Maybe logout is simple because logout is just delete.

E

The file right- that's not what logout means to me. Logout means to me that you delete the cache and you tell the server to delete the session.

E

It has to at least also revoke the session on the server right, because sometimes I log out, because I like pasted my session into slack on accident, and I need to fix that by logging out.

E

Now I do think that would be relatively easy to implement, because I think there's an rfc that fossid already supports. We just have to like wire it some in some way and give ourselves like an end point. I do think. Well, I think, last time I checked, it is actually something that you can expose in the oic discovery, so it wouldn't even have to be like hard coding like the supervisor logout or something that's the magical, logout.

E

B

How would you uh would we do anything special? If so, if you log out- and we like revoke your refresh token, would we also so in in the in the future case where your your downstream refresh token is linked to an upstream refresh token in oadc?

B

Would we also do something with the server then also try to revoke the upstream one.

E

Maybe the the reason, the only reason I don't immediately immediately say. Yes, is um I've never fully investigated this?

E

But if you look at the issues around this type of stuff in dex, there seemed to be some concern that at least in some oidc providers in particular, google, a particular client and user combination was only allowed to have one refresh token active for all possible sessions, meaning you know if you log into two separate machines as moyer through google logging out on one of them is not supposed to log out the other one or maybe maybe it is in some scenarios, but not always necessarily like you probably have to look at you choose with logout means in that case.

E

But if you imagine you revoke this singleton upstream refresh thing, then you kind of get in this weird state where it like hoses a bunch of stuff that maybe wasn't supposed to, or maybe it is. I don't know like I I um I certainly don't mind the capability of saying log out, like all like just nuke all my sessions everywhere.

E

Kindly because I I don't know, I changed something or I thought I lost something. Instead of trying to figure out what I lost, I'm just going to delete everything start over. um That's totally fine, but I don't know if that's like the default behavior.

E

Like I don't know, I if I was using, pin pad and me logging out of, pin pad shouldn't like log me on gmail. I don't want that to happen. That's just annoying.

B

Okay, so there sounds like maybe there's just more uh discussion that will need to happen in that issue before we have actionable stories out of it, but uh we can start tracking that, at the very least.

E

I do think we have a story somewhere about implementing logout. I think um pablo had asked for it like, but not like, specifically asked for it, but he had made like, I think, a story about it at that.

A

Time anything further on this particular item.

A

All right looks like there hasn't been any other discussion topics added. Does anybody have anything else they they want to talk about before we we head.

A

Out nope, okay! uh Well, thank you, everyone for today's meeting and discussion and uh if you're tuning in from home, watching us on youtube, we do invite you to to attend these live. We meet every first and third thursday of the month at 9 a.m.

A

Pacific time, um that's just an opportunity for you to listen in on what the team is working on and also provide your own uh feedback on what they're working on or, if you're interested in helping out with any of these items or if you have anything that you wish to discuss with the team on on your end regarding pinniped uh this. This is just a great opportunity for for all of that.

A

um Additionally, we are available on the kubernetes slack workspace in the pinniped channel and we are on twitter at project pinniped, so there's uh just various opportunities for you to engage with the maintainers, and um we do hope that you do reach out to us. We'd love to hear from you and with that. uh Thank.

A

F

Thank you nancy. Thank you.