VMware Pinniped Community Meeting, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped Community Meeting - July 29, 2021

Description

Pinniped Community Meeting - July 29, 2021
We meet at 9am PT every 1st and 3rd Thursday of the month (except for this time, we met on the 5th Thursday). We'd love for you to join us live!

Agenda notes from this meeting here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?view#July-29-2021

A

Hi everyone welcome to this week's edition of the pinniped community meeting. These meetings are held every first and third thursday of the month at 9 a.m. Pacific time. So, if you are watching this from home on a recorded meeting, we would love to have you join live when you are attending these meetings. We ask that you please read and abide by our code of conduct, which is listed here in the agenda.

A

If you're unable to attend these meetings in person, I would like to get in contact with the team. You can find us on slack and twitter, as well as in github. Of course, these details right here outline how to get a hold of this in the kubernetes like workspace within the pinniped channel, as well as on twitter at project pinniped.

A

If you have anything that you wish to discuss in this meeting today, please put that down in the discussion topics section at the agenda and we'll get to it after the other items.

A

Also, when you attend these meetings, we ask that you put in your name in the organization or company you represent. This is just a way for us to keep track of those that are attending our meetings and we can keep those lines of communication open.

A

As far as announcements goes uh just a reminder to, please register it to attend the pinniped cncf webinar, which is happening on august 24th 2021 at 10 a.m. Pacific time and if you click on that link, it'll take you here and uh you might have to create a login to rsvp and the maintainers matt moyer and marker crawford are going to be the speakers for this webinar.

A

And as I am speaking, we someone is putting in one of the announcements, uh I'm gonna assume it's matt yeah.

B

Yeah we're uh we're releasing or planning to release 0.10 today, um so that will have sort of two uh features. Two new features: one is support for logging in from machines without web browsers, like ssh, jump posts, sort of the main use case, and then I also have some new support for doing the ldap login flow in a non-interactive context, from a cicd job by setting environment variables and then also has a few smaller features and bug fixes has support for outbound proxies in the supervisor.

B

Oidc identity provider has support for oh, and then it has a has a bug fix for correctly merging on the impersonation proxy service, which is a bug that can cause performance issues anyway. That will be out later. Today we have a blog post, planned that'll, go with that.

A

Awesome thanks matt, that's exciting, all right! Next up status, updates um on the project roadmap, so.

B

Yeah, I can. I can dive into this too. uh We uh anjali- and I adjusted some things here this morning to reflect reality. um We did make one priority swap as well so remote oidc, login support happening today so that that is going to release in july, which is good because it's july 29th um ad support is waiting to be merged. Basically, uh we have a couple of last potential features that that we're still trying to iron out uh details about um global catalog support and how that should work exactly.

B

But marco, I think, like basically like your branch has been stable for a while now.

C

Yeah, the main uh feature set is pretty pretty much done. There's like a couple. People we've reached out to for kind of validating some of it, some people who know more about a.d than you as a team, so sort of defending that, depending that global catalog support.

B

Yep that sounds exciting, so uh other context here is a lot of the vmware team is taking pto in august, so it's gonna be kind of a light month, uh but we're hoping to do another release towards the end of august. That'll have aed support.

B

And then the next roadmap item is this multiple idp supporter, which really means on the supervisor having a federation domain with multiple, multiple identity providers configured and giving users multiple ways to log in that ryan has a design doc for that we're going to go through later in the meeting um and then as well uh a road map item for wider concierge cluster support. um I think this is a little bit vague.

B

I think the main one that we're gonna add is open shift support it's a little open-ended about whether there's anything else that sort of be easy to pick off. But I think, though, you had like a you, had a proof of concept a while back about how to make the concierge work easily on uh openshift, and I think this this will be essentially productizing that that proof of concept.

D

Yeah there was the open question about um the csr kept that we discussed last meeting. If you would go that approach or if we would do both things together,.

B

D

Sort of lots of.

B

Coverage, I think we might want to do both things. That's a good! That's a good point. I forgot uh yeah kubernetes is releasing here in in mid august, so this would be a good time. We could. We could add, support because we'll be able to like start using the 122 client libraries with all the right api types and start building that in in september for sure in august the things that we swapped.

B

So we did swap that multiple idp support one higher than the concierge cluster type support. um That's we sort of saw multiple idp support as kind of a table. Stakes thing that people probably would assume already works. If you were just sitting down for the first time with benefit, you would looking at our apis. You would guess that this already works somehow and it doesn't so. That feels like the bigger priority to to sort out yeah and the rest of the road map is unchanged. um I didn't want to call out.

B

I don't know if it's I don't know. If you all talked, I think I missed the last community called on the identity, transforms uh roadmap.

A

B

There is a experimental pr open that ryan made, that uh is a exploration of that using starlark as like a policy language. It's super cool and you go check it out.

A

Do you have a link to that matt.

B

Yeah, let me grab it.

A

And we can put it in the if you want to just put it in the agenda.

C

A

um I put something in here from the previous meeting just to see if there's any updates to it, considering using the functionality provided by tsr duration, captain 1.22 to broad and supportive clusters without the need of the impersonation proxy.

A

Does anybody want to talk about that? Was there any movement up there.

A

um From the previous meeting, this right here.

B

Essentially, that's the same thing we were just talking about, um but.

A

I guess the update.

B

Upstream is that, although all the things we needed to be merged are merged right.

D

Yep, everything is merged, boxer merged. I know somebody will probably nag me for a release note at some point soon, but uh all the functionality is immersed uh as beta in 122. it's enabled by default, so we can use it in 122.

D

um but yeah, so it would allow in at least some environments, uh uh an approach that no longer requires the impersonation proxy.

D

So whenever we get around to adopting that we'd sort of make it easier for adoption of the concierge, because the impersonation proxy does require networking configuration that may not be we, we can't necessarily automatically do it. We do sort of automatically do it in some situations, mostly when you like cube ctl, apply stuff, but not it might be production deployment.

D

A

Well, thanks mom, uh okay, moving on to discussion topics, the multiple idp support design.

A

A

Who wants to discuss this.

E

So I can take a shot at this. Maybe I can share my screen, so I can point with the mess.

A

E

All right, can you all see that.

E

Okay, so uh this is hot off the press. um It's just. I just finished this yesterday evening, so my teammates have not had a chance to read it yet, so it might make sense for this to be more, like just a brief introduction, brief overview of the document, the document is meant to just create discussion. It's not meant to be like a super, concrete proposal saying this is definitely what we should do.

E

It's just more of a straw dog proposal to create discussions, so we can all start brainstorming all the details and put together a more concrete design together, so maybe just kind of introduce it, and then we can kind of defer the the critiques the brainstorms until everyone has had a chance to read it. We can do that together at a later date. Does that sound okay.

E

um So start at the top. uh What are we talking about here? um I think, if we back up, we created this api in the supervisor called the federation domain and when we dream that up what we intended it to be is to represent a pool of users to provide identity to a pool of kubernetes clusters, and we implemented that second part where you can create federation domains and create as many as you want in the supervisor, and each one provides identity to a pool of clusters.

E

Any cluster can sign up to trust that federation domain and to get identities from it to allow to perform the authentication for that cluster.

E

But what we didn't really do was that first part, we didn't really create a way for federation domains to distinguish users, so all the federation domains today they all use the same underlying identity provider, and we only let you define one of them and so, basically, all federation domains are equal because you can't distinguish pools of users and put policies on federation domains.

E

So that's really what multiple identity providers is all about. It's letting you to find lots of different identity providers and then decide which federation domains we're going to use which identity providers and specifically, how are they going to use them.

E

um So it started out the stock with just kind of brainstorming, a couple of different use cases where you might want to do something like this. So, for example, I'll. Just I'm not going to read this whole book to you, but I would encourage everyone to to read it after the fact that the link is already shared.

E

I think, from h of the duck, but just for example, one possible use case might be uh maybe you're in charge of creating pools of clusters for development teams, and you would like each development team to have its own pool of kubernetes clusters, and you want to make sure that only people who belong to that development team can log into those kubernetes clusters. But you would like all those identities to come from your corporate identity provider.

E

And so theoretically, you could create a federation domain per team and then you can tailor each federation domain so that each pool of clusters that belongs to a team could only be accessed by those team members.

E

Several other examples follow encourage you to look at those. Then the doc goes into an overview of just to remind us and to remind myself: how does it work today? What are the limitations that we have today? Why do we have them? uh It goes in there's a bit of a summary goes into more details. It has links to the source code.

E

The basic idea is today: we only let you define one identity provider, no good reason just because we didn't have time to design to do this design work with how multiple identity paradise should work when we release the supervisor initially so today you can define one all federation domains use it equally, which unfortunately makes all federation domains kind of interchangeable and equivalent to each other.

E

That's what we would like.

E

I also thought about. uh We already have clusters out there, and so, when you upgrade your supervisor to some new version that supports multiple identity providers, there's some things. We should keep in mind. How are we going to try to make that a submitted upgrade? um So what what's out there today is kind of summarized here in these sections and then lots of questions that I'd love to have everyone chime in and share their thoughts uh on the dock or in a separate follow-up meeting.

E

So I just started asking questions and just dumping thoughts into the dock about each question. um These again, I'm not going to read all these to you, but please take a look at them. There's a lot of thoughts in there. Please add your thoughts. More importantly, please what questions did I forget to ask, so please add more questions as well, as you think about what are the things?

E

What are the things that we would have to explore and answer before we actually come up with a really concrete design for this and then finally, I sketched a straw dog proposal. If you're not familiar with the term straw dog, it's uh it's the brainstorming seed. So it's not meant to be the final answer. It's meant to start a conversation and in this strategy proposal.

E

um What I suggested as a starting point for discussion is basically summarized with um this conceptual difference between identity providers and federation domains, which is that an identity provider like an oidc or ldap, or a very student thanks to margo an active directory identity provider is the thing that knows how to talk a specific authentication protocol or talk to a specific kind of identity provider, specific kind of server.

E

It knows about the schema of that server, so it knows when I get a user record. How do I pick things out of the schema of that record, and so it can authenticate a user against a very specific type of identity provider, server, there's a federation domain.

E

I think it might be nice if that took that normalized view of a user that could come from any kind of identity provider and then allowed you to project that user uh down into a pool of kubernetes clusters and potentially customize, that user transform that user or apply more policy to that authenticated.

E

Normalized representation of the user on its way down into those downstream workload clusters, as we sometimes call them, uh and so the rest of this proposal kind of just goes follows the logic of that separation of responsibilities and tries to come up with a way that might make that, hopefully very flexible and somewhat easy to use for folks.

E

uh Maybe I'll just leave it there because there's there's a lot to read, there's a lot of details, but uh that's maybe enough just to give everyone an overview. They can go look at the dock and we can kind of start a conversation based on that. Does that sound right.

B

Yeah, I think that was a good overview, I'll lose the stairs to dive into design questions, but I think, uh in terms of scheduling, I think we'll be ready to pick up this work somewhere toward into september. So maybe we should uh sorry no. This work, I'm crossing the streams here. This work ties in a lot with. I think the starlark identity transforms work as well, so maybe it makes sense to uh combine those which I think would mean that the feature lands like in september october time frame.

B

um This feels like a really good start to like start that discussion. um This is like the big to me. This is the biggest feature of pentapet that we've known about since we started building it and we haven't designed yet we kind of knew that we wanted all of these things almost from the beginning. We just knew it was gonna be hard, so we put it off until we had the basics and we're almost ready to build that. So that's it's really exciting. To me.

B

I think we're really excited about starting this.

D

Yeah, I think other big feature that we kind of know about. Having done is uh arbitrary idps like github and all their friends like we know we want to add that we just they get somewhere in our, uh not that our backlog and stuff for various things uh we'll get there.

D

Thanks for putting that together,.

E

I look forward to having some team discussions around it as soon as possible. After everyone has a chance to read it.

A

Cool uh did anyone have any further comments on that and was there anything that something's come up that anybody wants wishes to discuss before we head out.

D

I wanted to make a little minor comment. This is really just meant as a thought um when you were talking through uh the design just a little bit. I don't think. We've ever discussed some kind of uh policy around the token exchange api itself.

D

So maybe that kind of fits into the whole federation domain starlark functions thing that today, you're allowed to do the token exchange. As long as the client has the right scope or like the original request at the right scope on it, that maybe you can make that fancier.

B

You think about things like restricting which users can pick which cluster audiences.

D

Yeah something like that like and you you know you could you could imagine that would be uh a different approach to accomplish the um like.

D

If you wanted to have one federation domain across uh many clusters, but only like developers could only use the developer clusters and I don't know it: admins could only use the production cluster or something like that. I don't know. um Maybe that kind of approach makes sense.

D

I I think the uh the benefit of multiple federation domains is it's very distinct and obvious separation, and the negative is also that it's distinct and obvious separation like you, must now have different like ingresses and problems, and all that.

E

Remember we um we're careful to make federation domains very lightweight, so you can create an arbitrary number of federation domains all under the same endpoint, the same tls certificate, because we let you just vary the path of the issuer to make a new federation domain.

E

So if, if your supervisor is at supervisor.example.com, you have one federation domain, that's supervisor.example.com developers and a different one at supervisor.example.com.

E

It slash production, yeah.

B

I think that makes sense it does it does. I think I think it. I think that supervisor configuration is not that bad, because of that it does mean, then that on the client side on the on the workload cluster side and the concierge it does have to like have a separate jot authenticator for each federation domain, which is okay, but it might.

B

It might also be nice to have an abstraction that says like oh this, this workload cluster trusts this supervisor, maybe maybe actually trust like a whole bunch of different combinations of these settings from that supervisor.

B

As obviously I think this document is a really good start, there's probably like a million little rabbit holes like this, that we need to go down and figure out um some of the trade-offs but yeah it's a good.

A

Start cool anything else.

A

Okay, um well thanks everyone for joining the pinniped community meeting today and just a reminder: if you're watching this from home, please uh consider joining us live. We meet every first and third thursday of the month at 9am pacific time, and we also can be found on twitter at project pinniped and in the kubernetes slack workspace in the pinniped channel. So we encourage you to join us, um you're free to come and lurk you're free to come and bring any discussion topics or anything you need help with.

A

Regarding the project, we would love to have you and with that. Thank you.