VMware Pinniped Community Meeting, 1 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped Community Meeting - April 1, 2021

Description

Pinniped Community Meeting - April 1, 2021
We meet every 1st and 3rd Thursday of the month at 9am PT / 12pm ET.

This week's topics included the release of v0.7.0 and the next project roadmap items for April 2021. Full details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ

A

All right uh welcome everyone to the pinniped community meeting, the first one of april 2021, uh just a reminder to please adhere to the code of conduct when attending these meetings, which is listed right out here in the agenda.

A

These are being recorded and will be added to our youtube. Playlist later today, we do have some pretty exciting announcements. Today uh we are cutting a release 0.7, and that leads us to um the update, in particular for impersonation proxy, since the release covers that- and I will kick it on over to whoever wants to lead the discussion on that and what to expect with this release.

B

I can give an update, um so this has been something that we've been working on since february. um The last release was february 11th. I think so. We it's a solid chunk of work. Essentially, what we've done is add support for uh the vast majority of real world kubernetes deployments with the concierge. So before this release, uh the pinniped concierge worked on a set of kubernetes clusters, basically where they were sort of self-hosted, where the control plane runs in the cluster.

B

That includes a lot of clusters, but it doesn't include any of the managed cloud provider services and so in o70, we've added a whole second backend strategy to the concierge supports those environments. So now we cover uh really a huge huge majority of clusters that people care about, and this should all be mostly seamless, like the installation process is the same.

B

It's still one command one command to install penfed on any cluster, one command to get a coupe config and that's it, and so we made sure that the user experience continues to be very low, touch very automatic in every case yeah. So hopefully I mean in some ways. This is a very small change to like the user experience, um but we've we've brought in support from some clusters to almost every cluster, so this will be going out today, along with a blog post.

A

Hopefully, awesome thanks matt super exciting to see that happening uh on to the next item on here, which would be uh the road map for april 2021. um I take it well, I'm assuming not too much has been worked on that, but I don't want to say anything um further.

A

As far as april 2021 looks like we have ldap support and device code flow, any updates there.

C

It has begun, we have started, is the update there.

A

C

A

Awesome week any blockers that you're, seeing so far as you start on this.

D

We're uh we're still in the technical design phase. I guess you would call it and so uh actor and I have updated the kind of proposed technical design, and I put that as a possible discussion topic. If we want to go over that more detail today,.

A

Cool yeah: let's: let's do it, let's get right into it.

D

All right uh should I share my screen or andrew. Do you want to go through this? Go for it you're hot.

A

D

All right, everyone see this hack, md document. This is publicly available by the way I put a link to it in the agenda for anyone watching the recording who wants to look at it.

D

It's part of a bigger uh technical design document for ldap, so the andrew and I have been working on yesterday- is specifically: um how does the cli talk to the supervisor to enable cli based login through ldap, where the cli prompts for your username and password and never needs to open a web browser, which is what it would do for an oidc login open a web browser in the web browser your otc provider would prompt you for your username and password.

D

um This is, I think, bat and pablo you've never seen this, so this is going to be a real live discussion, so your feedback is, of course, welcome. Everyone's feedback is welcome, uh andrew and I thought one possible way to do this. That might be. Nice would be to lean on the oidc issuer to use the all ready, publish, discovery, endpoint and add some custom information into that.

D

So issuers and the supervisor correspond to the kubernetes api object that we call federation domain. Each federation domain becomes an oidc issuer and each issuer then has the oidc well-known discovery endpoint, and so what we're proposing is that each issuer, aka federation domain, advertises publicly what upstream identity providers it wants to advertise publicly. So it could be, for example, that it advertises all of them all of the currently configured upstream identity providers or maybe down the road. We have some features where an administrator can say.

D

I want to advertise these ones publicly, but not these other upstream identity providers and in the public advertisement it. It obviously is not going to share any private information. So it's just an identifier, a type to tell you if it's oidc or ldap and if it is ldap, it's very common to allow administrators to customize.

D

Your discovery document.

D

All right, okay,.

B

Question about that, so I wonder um if so I think I like the idea of advertising the idps here. I wonder if, instead of actually sort of keying off ldap versus oadc, if we should just key off of password-based grant flows or web browser-based grant flows, so I'm thinking ahead like if we added saml support as a browser-based flow.

B

The cli client actually shouldn't really have to care about that, because in both cases all it does is open up open an authorized endpoint in the browser.

B

It might still be useful, I guess for like. If we have an interactive selection, it might be a nice seo. This is an ldap provider. This is a saml or oadc provider, but maybe it would also be useful to just say like oh and if you don't.

E

Care about that.

B

Field, you can also know like what what front-end type this is. That makes sense.

D

um Yeah, to a certain extent, our login cli command doesn't really care right. It just needs to know if it's web-based or not web-based, um I think maybe, when we get into the get coop config command, that's where it might be helpful to know the specific idp type, let's maybe jump into that next and yeah. Of course, we could. We could change that or we could add an additional field to say if it's web or password-based, uh so piniped get coup config. So a reminder for people who might be watching the video.

D

This is the command that you use after you install you use it as the administrator, and it gives you back a cube config that you can then hand out to your users, so you get one coupe config, there's no identity, encoded in it. It has no passwords encoded in it. It's safe to give it to all of your users. You know all of your users can use it to log in so today.

D

The way that that works is it typically, you would use it against a workload cluster that workload cluster has the concierge software installed on it, and uh the key thing is that piniped get coop. Config doesn't even know that there is a supervisor cluster or a put a pen supervisor app running elsewhere in the world. It's unaware of it blissfully agreement.

D

um So that brings us back to discovery, uh because pinniped get coop config can see that the concierge has a jot authenticator type configured.

D

It can know that there is an issuer which would be specified in there and it can do discovery against that issuer without knowing whether it's a supervisor or just some generic idc provider, which means it can look for this custom fields. In that response, and based on that custom field, it can choose to act differently.

D

So what we were proposing is two new fields. When you do uh excuse me new flags, when you do pitifully get a cube config, you can specify either none of these new flags or both of these new flags or just one of these new flags.

D

So you can say my upstream idp is this name and or my upstream idp is this type, uh so you can say. Basically I want a coupe config and I want it for my ldap idp or I want to keep config and I want it for my idp called corporate idp and it would give you back that good config through a kind of best effort discovery and comparing what you asked for versus what's available and if you ask for nothing, the idea is.

D

If there is exactly one choice available, it will make that choice for you. But if there are multiple choices available or no choices available, then it can error and show you a list of choices that are available.

D

Pause that for a second.

B

Discuss yeah, I like I like this: is it it? We.

B

When we're, when we're running this gatekoop config command, we sort of assume that we have access to the workload cluster where the concierge is running, we don't necessarily have any access to where the supervisor is running so, like the discovery, docket seems like a really natural place to put that, and it it's a existing api. That's meant to be extensible for this kind of thing.

B

um It's a trivial api to like build with, because it's just this sort of json structure we can put our custom stuff in there.

C

Yeah, this seems great. This I mean obviously assumes if there are multiple idps that the developer knows, which one that they need to log in through right. Do we have any evidence that supports that a developer would know the right off path.

D

Yeah, that's that's a great point pueblo, um so usually the pinniped. Yet config would be done by the administrator who created the cluster, and so hopefully they because they created the cluster. They would have configured the multiple idps or maybe they would be closely related to the team that runs the supervisor and configured the multiple idps.

D

So hopefully they would be able to select on behalf of their end user, their their kubernetes developers or whoever it is that they're handing this cluster to and then they can hand them the fully formed config. That already has that selection baked into it.

C

Okay, that makes sense. Thank you.

B

And also like also, it seems it sounds like if you can control which idps are advertised.

B

This way you could have if you were like a administrator, and you knew that you had like the the main login flow through corporate sso and then, like maybe a backup login flow through of some local directory.

B

You could choose not to advertise that one, in which case anybody using git, coupe config this way would not have to specify anything and they wouldn't get prompted. They would just default to that. The one that's preferred right.

B

Does that also.

E

B

That also mean that if you do set those flags, you can set them to a value that doesn't appear in discovery.

B

Oh that's a good point.

D

uh Yeah, we should think about that. I don't think we wrote that down. Maybe you can add a comment to the doc here, while we're talking about it think about how that would work, because that would be nice as a feature, I think potentially, uh but thanks pablo for mentioning multiple idps today, pinniped doesn't support having multiple idps configured in your supervisor at the same time, but it's something that we've been planning to do and we've always kind of danced around it.

D

Knowing that we will do it someday, it was even in our backlog, our prioritized list of work we just haven't got to it yet, and so this design, I think, actually plans for that and gives us the framework to do the multiple idp support.

D

It's kind of killing two birds with one stone.

D

All right so assuming that, then you have a coupe config generated by uh what we talked about pinpoint get coop config, then that coupe config is going to have in it embedded a piniped login oitc command with all the flags already specified.

D

So let's talk about how we would enhance this command.

D

um What we're suggesting is that it takes the same two flags again where you can specify the name of the idp and the type of the idp, but in this command you either must specify both flags or you must specify neither of these two flags.

D

One of those two choices you can't just this command meant to be a little less uh automatic, self-discovering and more just told exactly what to do.

D

So. If you specify both flags, then the cli, the cli, is going to do discovery anyway, because it's an oidc login. So it's always going to do discovery anyway. So since it's going to do it anyway, it might as well take the idp name and the idp type that you asked for and make sure that they appear in the discovery document and to matt's point earlier. Maybe it's okay! If they don't appear so we have to think about that um and then, when the those new flags are not specified.

D

We have some options right, so we're still gonna do discovery.

D

um You could hit the discovery endpoint and not get any of this custom uh field back, which means you're, probably not talking to a supervisor you're talking to like google or somebody else, in which case we can just do what we used to do um otherwise uh for backwards compatibility if it sees that there is exactly one idp listed and that idp is of type oidc.

D

That knows it's good to continue because for backwards compatibility, if you didn't specify these flags like if you have an old coop config from before we implemented this feature, these logs aren't going to be in there, but if there is exactly one idp listed in the discovery and that idp is of type oidc and it can go ahead and do what it used to do.

D

Otherwise, it could be an error or again we need to figure out some maps. Matt's comment.

D

Okay, now once it's decided that the input is correct and it knows what idp it wants to log into, how does that work andrew and I did a spike or actually implement 3d version of this, uh my prototype, and so what we're suggesting is that we now that the cli knows that it's a an idp of type ldap.

D

It knows not to open a web browser. It knows to prompt the user for their username and password. It even knows what your custom prompts should be for the username and password from the discovery document, so I can go ahead and prop the user and then, rather than opening a browser and.

D

Starting that whole idc flow, it can hit the authorized endpoint, which is the first endpoint in the normal oidc flow, and it can post some custom query parameters to say. I would like to log in to an idp of this name of type ldap, and I could also post some custom, http headers. To say this is my username.

D

This is my password that authorized endpoint would then be able to verify all those inputs make sure that that username and password match the ldap system, and then it can complete your login by just immediately redirecting with the auth code to your requested. Redirect uri cli can get that re that 302 response. That is the immediate response to its first request, and then it can just do what it normally does to complete the odc auth code flow. Get all your tokens get you logged in the rest of that sort of change.

B

Was there because there's one more topic after this, so this means that uh even even this local password-based flow still requires opening of the the listening port. For now,.

D

But but actually we can it's an implementation choice, yeah. We can either client report and let the code do what it does today or the client could not open the port, get the callback response, the 302 response, look at the location, url parse, the auth code out of the location, url and just use it immediately without ever opening the listening port. That's obviously, when you think about the code that would branch the code so that the ldap code shares less code with the oidc in the cli.

B

But that's the biggest! If we, if we, if we, that that change is only a change in the client there's no service. The server side of behavior in either of those cases is the same.

D

Either way it's just a 302 back to your original, redirect uri with the query prime, which is your author yeah. The.

B

Client can decide how to interpret that this would also support in the future. Maybe this is where you're getting to next. Oh okay,.

D

Yeah, so uh we wanted to make sure that in the future, it should be possible to also perform this style of ldap login from other clients other than our first party cli based flow.

D

We don't need this today, so we're not proposing that we build this today, but we want to make sure that we leave room for it, because it's something we've talked about, maybe would be in the future roadmap of pinniped.

D

This would, for example, this would be like um third-party dashboard web uis that are running in your kubernetes cluster log into these dashboard web uis, using their own identity with their own rpec permissions and then perform whatever actions they want in their cluster through web ui. That web ui would presumably become an oauth client to pinniped and would want to do the traditional web-based oauth author or the auth code flow.

D

So I want to leave room for that, and I think this design does leave room for that, partly because the custom parameters that we're proposing we add to the authorized endpoint the custom headers for your username and password are things that should not be used by third-party clients.

D

In fact, if a third-party client, if they're when I say client, immediate oauth client, uh if an oauth client other than the pinpoint cli client tries to send those custom headers, we should probably error because we don't want to encourage third-party clients to ever handle a user's password themselves.

D

So that would be first of all, a browser wouldn't send custom headers in the first place, so it's very unlikely that they would do that. But just in case somebody tried to write a client to do that. We, the putting the idp name and idp type as query parameters, means that a third party client could specify them if it wants to. So it could be.

D

That and then we could redirect to a custom login page posted by the supervisor, so the supervisor has a web form that way, only the supervisor is handling your password and the third party app is not uh so the third you submit your using your password through the web form for the supervisor, and then it can complete the lidc flow. It's kind of standard way to hand the tokens back to the client and sketch down here all the technical detail of what that might look like.

D

I think that was all any anything on leaving room for potential web-based.

F

Vlogging just to be clear, we would not build web-based login anytime soon, right or at least that's not on the roadmap for anytime soon.

C

Exactly it's not on.

B

C

Road map right now, but I mean yeah, it's not otherwise, right now,.

B

uh My question is so this I like, I like the design um like says. After after doing this spike on design and a little bit of the prototyping, did it make your estimate of the level of effort here for ldap go up or down.

D

um So we never talked about it in the community meeting, but there was a earlier version of this uh design.

D

That was, I put a little bit more burden on the client to make a couple of extra redirects and follow those redirects that earlier version meant that there was only going to be a single way to log into ldap whether it was web-based or cli, based and based on whether you asked for a json flow or html flow. It would act differently, but still the same underlying code would implement both the webflow and the client flow.

D

um This second draft takes that away, and so it means we're going to have two completely different code paths.

D

If we, if we eventually do add the web-based flow we'd, have basically a separate implementation, obviously could share a lot of the code but different endpoints with different implementations.

D

um So I think this proposal that we just went over together simplifies the work that we're gonna do now simplifies the client side a little bit a couple of less redirects to follow, which is what we're going to do now. So that's simpler, so it feels like it shouldn't be. Very hard- and it defers the slightly harder version for later, which is probably a good thing.

F

I feel like on on the topic of complexity.

F

I feel like the most difficult part and ryan- and I were talking about this yesterday- I feel, like the most difficult part, is just to be fighting with ldap dependencies so like getting an active directory up to test with and trying to hook into that and, like those complexities, still exist in this design. So.

B

Yeah, that's really fair. I think we haven't even really figured out if we're gonna have a way to test all of this locally in a kind cluster and like we use decks, and we use that special local user authenticator web hook that we wrote to do local testing of the other pieces of code.

B

um Nothing immediately jumps out as the solution for this, but maybe we could figure something out.

D

B

D

Tested this kind of thing before by using open ldap with a hard-coded eldiff file to initialize it. So you have a hard-coded set of users and a hard code instead of groups and those belong to those groups in a hard-coded way with hard-coded passwords.

D

um That makes that's actually really easy to implement and I honestly haven't done that in kubernetes, but I think it should be easy to containerize uh open ldap, because it's just a unix statement. There probably is already a containerized version out there somewhere that we can.

B

My other question so, like level of effort sounds like still pretty complex. No, there was there was nothing here that we discovered. That's like that blows up the complexity more than we thought, which is good. My other question is: did we break down the work correctly?

B

It sounds like maybe there's at least some chores that popped out like setting up that open ldap could be a separate chore, or maybe it's not. Maybe it's just part of that. First, big story.

B

I know our breakdown was pretty product focused, and I think that was good, because we still have the intention to deliver the product features in the same way.

B

But I don't know if any of that needs to be tweaked, given architecture.

F

I was pretty pleased with the breakdown that y'all did. I think that kind of still makes sense just kind of incrementally adding to the api, which is the ldap identity provider, and then hopefully the integration tests will just mostly stay the same. I do agree matt, I feel like I envisioned in the first story that really big story.

F

You have like 10 tasks that fall out and one of them is is maybe setting up some test infrastructure and the other tasks are like writing the controller and writing the off hand and point and writing the cli necessary. So I feel like y'all's breakdown is still good. I don't know if ryan you have other opinions.

D

Yeah, I think so that that first story is a bit of a beast, because it's the uh get the basic version of everything working all at the same time, but as we discussed before, we couldn't think of a better way to break it down and have that first story still deliver user value.

B

Yeah, I think we- and maybe this is a little bit of a reaction to how we built the ldap, the uh impersonation proxy, where we did break it down more and then it turned out. We just kind of like kind of keep iterating on all of the stories at once, until kind of they were all acceptable. At the same.

D

B

We split them up more.

D

But it didn't actually help us, we might be able to learn from that and uh we could make the first story of feature branch. A pr branch finish the first story and then merge it because it will be a very incomplete implementation, but the way we wrote the first story. I think it will be a a secure usable implementation.

D

As long as you only need this very narrow set of configuration options.

D

That was harder with the impersonation proxy because I kind of either completely worked or you couldn't use it at all.

F

One other thing I was going to add: I this is a no-op. I think for us on the call right now, but mo is out right now and he gave feedback about the api endpoint that is used for discovery, and so maybe there will be more discussion on that, but I wanted to give him space to like give his feedback once he gets. Her get back, gets back from his time off.

B

Yeah, I think that's fine. We well at some point it's just too late and we'll just build the thing and ship it that's okay, too, um but that I did. I didn't think like that. That is a that is another new. The discovery document is another new api, like, I think, a relatively low stakes api, because when we own both sides of the connection- and we can tweak it in the future, it might be nice, though, to put a uh version in there.

B

So maybe we could have a subfield of the discovery document that then contains something that looks like a kubernetes type that has a kind and an api group and version that way. If we needed to change it, we could change it using kubernetes style, api, schema, migration and advertise. You know basically.

E

B

An intermediate state where we advertise both versions for a while things like that yeah.

D

This is actually something that andrew brought up and we discussed yesterday about like well. How are we gonna version this, and I think what you're hinting at here matt is that we can't version the api itself like the path, because the path is specified by oidc.

D

It's a standard. We can't change it it does that standard does not allow for versioning the path um we could. If we wanted to add query parameters, so you could say, like question, mark v equals two. If you wanted to get version two of the custom fields of our discovery, dock or we could build it in into the json response into the custom part of the json response, like you were suggesting that I suppose.

B

D

Also use like content type negotiation, technically yeah yeah. Absolutely. um I think what andrew suggested yesterday was.

D

Maybe we don't need to worry about that now, because by not mentioning a version in any of those places, any of those possible places. It's implicitly saying this is version one, and then you still have room to add on a query, parameter or version in the json or anything you want later. If, if you ever need a version too, as long as the json, the future changes that you want to make to the json are backwards compatible.

D

You can keep enhancing it without ever needing to introduce a version. It would only be if you want to make a breaking change, so you have to figure out how to introduce a version.

D

Did I characterize your assessment correctly injury.

F

Yeah, I think so I think that's what we talked.

F

A

uh Anything further on this particular.

D

Topic: okay, we'll talk more about this topic, I'm sure, but thanks for the discussion and the feedback.

A

um Before we part ways I did want to welcome scott to the community meeting. um I know he showed up just a little bit past some of the stuff we already covered, but I would love to hear more about about you, scott, if you want to share with the group um where you're based so what you're using pinniped for and anything else, you want to share.

E

Definitely so hi everyone, I'm uh scott rosenberg based in israel.

E

I work for terra sky, which is a um professional service organization, uh dealing with uh a global partner of vmware's and dealing a lot with also public cloud and very strong in the devops and kubernetes world, and I'm leading the um cloud techno, I'm the practice leader for cloud technologies and automation um and leading the whole tanzu portfolio for all of our customers. um So dealing a lot with pinniped these days, looking into it, um was using decks and gangway uh have a lot of tkg uh projects by customers so very happy.

E

Now that piniped is integrated there um and been testing it rigorously um and definitely seeing the use cases for a lot of our customers with the impersonation proxy, uh especially with their uh gkn eks customers, us that we have as well um so just wanted to join here and uh yeah and meet the guys here and uh happy to join in uh future community meetings as well and uh learn about this project and hopefully contribute in the future.

D

E

D

D

G

D

Your feedback too so pop into our slack channel, come to our community meetings. Can't wait to hear about your experiences.

A

um Ryan, do you want to introduce yourself and then I'll, ask andrew matt and then uh anjali.

D

Sure yeah, my name is ryan. I'm one of the engineers on the team, along with andrew matt and two other folks who are out of office today and I've been on the team.

F

F

I'm andrew, I am like ryan, said, also an engineer on the team also been here since we started like junish last year. I feel like was when everybody first got together. I know there was some folks working on this beforehand, but that's me.

B

Yeah, my name is matt. I've also been working on the project since around june um yeah I mean my previous kubernetes identity contribution. Was the aws im authenticator its uh authentication flow on eks?

B

I came in um from peptio anyway. Super excited.

F

E

Yeah great to meet you guys and uh definitely have used uh your work in eks before so. uh It's always nice. Hopefully.

B

Hopefully, good experiences, it can be uh every object. Every auth system is frustrating to set up so.

E

Exactly pinniped so far has been one of the easiest. So uh definitely looking forward to the ldap integrations as well and uh to see what happens with the product.

G

Hey scott, uh I'm anjali telang I just joined. This is my first meeting as well, and uh I am a security pm working with pablo uh who, who is a member of the project so um x, red hatter. uh You know been with openstack openshift uh working on security for a while. Now.

E

Great well great, to meet you all and uh look forward to uh meeting with you guys in the future as well.

A

Great thank you for sharing uh and thanks everyone for introducing yourself and for the lovely discussion topics. um Scott was there anything in particular that you wanted to talk to the team about today or you just wanted to kind of join and listen in for the first one.

E

uh Just lying and just join and listen in uh today, I've actually watched all of the community meetings that have happened till now on youtube as well. I just haven't been able to join and uh hopefully should be able to join in the future.

A

Wonderful yeah, if you have any feedback you have as far as improving the community meeting, please feel free to share that with us in the the pinniped slack channel. We'd love to hear your thoughts.

E

Definitely great.

A

Okay, so um does anyone else have anything they wanted to discuss before we say.

A

All right, uh so the next meeting will be april 15th. We do meet every first and third thursday of the month at 11 a.m: pacific time, 2, p.m. Eastern time.

D

9 a.m: pacific.

A

Oh, my god, um 11 a.m. Central time, uh all right with that, we hope to see you at the next meeting and thanks for joining bye.

G

Thank you so much.