Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2016 (Seattle), 16 Nov 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Auth and Access Control by Eric Chiang, CoreOS

Description

Kubernetes Auth and Access Control - Eric Chiang, CoreOS

Learn how to limit access to Kubernetes, lock down components, integrate with identity providers, and use the newly added RBAC types for fine grained administration of clusters. We'll explore Kubernetes auth from 10,000 feet, all the way down to tricks and quirks of individual admission plugins.

About Eric Chiang
Eric is an engineer at CoreOS where he works on integrating user auth technologies with Kubernetes.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

So I know it's tradition to start talks about five minutes late, because people are still you know coming in, but I have a lot of slides to get through today and a demo I. Don't know why I put so much content in here, so I'm, just sorta gonna get started so hi, my name's Eric. You won't miss much of this talk at the beginning, so if you're still coming in no worries so hi I'm an engineer at core OS a bit about me, I am one of the speaking styles that totally likes audience involvement.

A

So don't like shout at me but you're, welcome to raise your hand and if anybody has any questions in the middle of this talk, please please please feel free all right. So why are you all at a talk about office early in the morning? I? Guess it's not! Actually this early so I'm going to make this terrible assumption, because you all are at coop con that you're going to go back to your normal lives and back to your jobs and you're going to try to deploy kubernetes clusters.

A

That might be an assumption, that's wrong, but that's the assumption that I am going to make today. Okay, so you are all now sis admins fun stuff. So when you are doing that, you're going to have to deal with this problem, okay, whether that's just I, want to whitelist some nodes or I want to. You know, set up multi-tenant environments for my team, or god forbid, your customers and you're going to have to deal with this. So that's what I'm going to talk to you about today, um a quick overview.

A

First we're just going to define what the problem is. Then we are going to talk about what users are in kubernetes, how kubernetes thinks about users? How that is different from your assumptions and so on and so forth.

A

Then we're going to talk about authorization, how we use that user information to actually make policy decisions, specifically we're going to talk about roles based access control, which is a new API in kubernetes that you all should be using and then for anybody like on sig off with me, you're going to be kind of bored for this, so we're going to show them a really cool demo at the end cool stuff. Okay, all of you have seen this a million times this last couple days. This is what kubernetes is yeah.

A

There's some diagrams um really important part about this when we are using kubernetes everything. Basically, everything needs to talk to this thing called the API server right. You create a deployment using coop CTL that talks to the API server and shoves the record a net CD. A controller is watching me at the API server sees that record is created and then acts upon it and creates a new like pods and stuff like that. So this is a scheduler. Does something similar the couplet notices that Beauvoir.

A

um So today we are going to talk about how the API server authenticates all of the clients that need to talk to it. Obviously you can't just have anybody talking to the API server we want to be able to? You know, make sure that only the people we want are talking to us and then, after that, we maybe want to start thinking about okay. What do I want to let each of these clients do right. The creeps ETL might have different permissions than the couplet or the scheduler, or you know your master controllers cool.

A

So there's actually been a couple of cool talks on how an 8pa request goes through an API server and we're going to focus on two parts of that. First, how does it parse the credentials and figure out who the heck is talking to it and then afterwards? How do we add additional policies on top of the information that we pulled out during that phase? So this is the classic authentication who is talking to me authorization? Can this person do what they want, and this is sort of going to be the split between this talk.

A

It's going to first talk about authentication and then we're gonna talk about authorization, so users in kubernetes I'm, going to tell will little white lie and say that kubernetes doesn't have users. Now, that's not entirely true, but that's really helpful for me when I am thinking about these systems. Whatever your view of what a user is, it is most likely not the same thing that kubernetes thinks of a user is as excuse me. Users are just strings.

A

So when you get a request, all a user is is additional strings associated with that request, literally just strings okay, so you might have the string like my username might be Eric. It might be Eric at course comm or something like that. But in the end that is just a string. Additionally, we might have groups which are also just strings right. So, while my request is coming in, I might say: I am part of the developer group or the Gopher group, or so on and so forth.

A

Your API server, though, is pluggable, so how we pull that information out is different for every API server that you will deploy or maybe different. There are very common ones like x.509, client auth. There are less use ones like web hooks and so on and so forth. But the important part is that this is a pluggable part of kubernetes right.

A

So when you are deploying something- and you want to think about authentication the authentication side, you have to make a decision when you deploy your API server about how your what you're going to accept so the most common one that anyone does is client, certs, right, I'm, assuming that anybody who has deployed a kubernetes cluster just uses client certs to talk, have their nodes, talk and your kimchi tailstock and so on and so forth. Right so question!

A

Yes, you can absolutely use more than 1 billion, so the question was: can you use more than one plugin by the way? Because anybody didn't do that so um basic structure, right I? Am the administrator I create a CA for kubernetes I, create you know, I have a key associated with that I then spawn off client certs that I hand to developers and put on nodes and so on and so forth right.

A

So, when I do that I'm going to get something like this right, so if I pop open one of those certs I'll go ahead and look at that and do whatever now normally when you are interacting with the API server, all you care about for the most part, all of your deployments or all of your sort of installations of kubernetes. All they care about is is this available when you turn on when you start thinking about authentication in a more fine-grain role and then have to think about authorization, these fields actually matter.

A

So if you can't see this, this is the common name of the client sort that I have given, let's say a couplet right, the common name is Kubla one and the API server will think of that as the username for any request using this client cert that added in 1/4, we actually pull group information out of the organization's.

A

So that means I can give client certs to my couplets, that say, organization couplets there in the Kubla group and then I can give clients or developers that have organization, developer and they're in the developer group, and then I can do stuff later with that.

A

So again, most people only really use the does this off. You know is this a valid cert, but as we start thinking about authorization, we're actually going to use that username and group information later on. There are a bunch of other plugins, some of them more elegant and awesome than others.

A

There's a couple ones involved in bootstrapping, so you can say like a token file if I show up with this token, as a bearer token I will be authenticated, as Eric I will have being a group developer and Gophers if I show up with the other token file, just like as a bearer token right authorization, authentication, authorization bearer one of those anyway, the header HTTP header that you all are so familiar with, there's also a web hook mode. So you can actually configure your API server.

A

Just like you would say, I want to use client a client CA, you can also say: hey. I would really like to use a web book. I would like to configure a web hook, so everything that comes in with a authorization bearer token uses sends it off to another service that you know determines what the user is for. This particular request: okay, cool cool note: this is what gke uses so Jiki a gke has very established credentials that it uses, but they obviously don't want to compile.

A

You know how to look up in the Google database, who you are so they just configure a web hook, do whatever just say: hey I'm, going to go. Look up this in some proprietary database to determine how who the person in talking to me is right. So if you have one of these hooks or if you have one of these proprietary databases, that kubernetes doesn't support, yet this might be interesting to you.

A

What do all of these have in common, though you cannot configure any of them through the API okay, you have to when you deploy your API server intentionally, decide hey I'm, going to prove this master with this API server with these particular flags and possibly referencing these files on disk. You have to do that. Okay, and importantly, it's completely managed outside of kubernetes. You cannot interact with normal users through the API, and this is sort of where I am getting at. Kubernetes doesn't really have users and then we're going to get to the lie.

A

So kubernetes does have users they're called service accounts. Service accounts are basically just bearer tokens managed by kubernetes, and these are the things that you can use through the API to create users as you want. Okay, so what happens when you create a service account, so I do cube. Ctl, create service account and I, give it a name and what I get out of that is. A service account object right.

A

So this thing is, you know, has the normal metadata, it has the same name: I gave it, and additionally, it has some lists of Secrets right. What that list of Secrets is is these are actually the credentials that the service account owns right. So if you look at that secret you'll see the see a CI cert for the API server, so you can talk to the API server securely. You'll see a namespace, it's basically four encoded, because this is a secret.

A

That's just default, and also there is a this thing called the JSON web token, which are you know, cool things. What that is is just a JSON payload that is signed by the API server. So when you come back with a service account token, the API server says yep I'm into this. Ok, let's go then so service accounts are used to actually give all of the pods running in kubernetes identities. Ok, so when you create a service account, you can then associate it with a pod running in the cluster.

A

Again, you can say service accounts, give it a name and what that will do is it will mount the secret into your kubernetes pod?

A

If you do not give it a name here, it'll just default to the default service account in your namespace cool, and by mounting this in, you actually have all the information you need to have a secure conversation with the API server and be authenticated as a particular service account right. So if you look at like the in cluster implementation, all it's doing when it's initializing its configuration, this is just the go client that probably all of you use to talk to the cluster, the API server inside your cluster.

A

All it's doing is reading that service account reading the CA and then using it later as a bearer token, and that's it- it's not particularly magic, but this is how we give pods identities yep.

A

umm Secrets are I, believe temp ephesus, so they're never touch disk, but that's the details of secrets. More than service counts, cool, so yeah. Another question.

A

Secrets are a can of worms that I don't have time to get into right. Okay, if you want to talk to me about secrets, which is a very interesting topic- and you know we are going to I'd love to have those conversations, but just not not quite right, now, cool, so service accounts in kubernetes. So again they have just weird names and they're just signed bearer tokens. Okay, they are just I, have some payload and do whatever and I actually have one right here, it's really ugly, but there's a site called JWT io.

A

That's really nice for debugging these things.

A

Okay, so this is my service service count. Token. Couldn't you tell, and all this is- is a header with some information like what the algorithm used to sign. It was there's a payload here and then there's a signature right. So this comes in and yeah the API server verifies that signature and unpacks the payload.

A

The payload itself actually has some cool fields, so it has like you know. The issuer is kubernetes, that's pretty cool, there's a subject which is the surface count name and actually, basically, my only trick that I know in all of kubernetes is that I, your namespace is actually in that service account, so the service account token. So all of you who are using the downward api like suckers, to figure out what namespace here in just parse your service account token and you'll figure it out instantly. I am also using that trick.

A

So I will be the first one bitten if it breaks in backwards, incompatible ways: okay, yeah they're automatically mounted into pods cool. They give each pod and identity in the cluster. And again, if you want to manage users, I, don't know why you would use kubernetes to manage users, because that sounds awful. You would use service accounts because they're the only thing that you can talk to the API thread and interact with users. Importantly, they can totally be used outside the cluster and, as we have noted, their credentials are stored in secrets.

A

What does this mean? Anyone who can read your service account secrets, can act on behalf of your service accounts. So be warned and don't give your service account tokens the ability to bring down your cluster because yeah cool.

A

There are some other options. We talked about the token webhook will review open, ID connect and all of its glory later when I talk about dex and there are some static file options which brings us to authorization. So you guys are all experts in authentication. Now now we're going to talk about authorization, authorization uses the namespace and groups that we pulled out of the credentials during the authentication phase and uses them to create a policy right.

A

So you know, obviously, if you have a group that is named specific things, you want to enforce policies around that I helped port it in 1/3 from Red, Hat, openshift, so shout-out to OpenShift they and the guys behind that they've been awesome, so yeah and we're going to talk about sorry yeah. We are going to talk about the specific implementation of authorization, one of the plugins and you can have multiple authorization.

A

Plugins two called roles based access control are back, ok, little high double view and then we'll get down into the dirty details so default for all authorization. Plugins, not just our back is deny all okay, it's a safe assumption, but it also makes setting up authorization a pain in the ass. You just have to go through this I'm.

A

So sorry as we proceed, we will try to give better guidance for how to set up clusters with the authorization, but we want to get our back to a good state in order to do that, so they contain a subject verb in namespace, so you can say something like user a can create pods in namespace B. You can also omit the namespace user. A can create pods in any namespace or for something like a node which is not namespace. You can say user B can edit pods or net nodes and omit the namespace.

A

What you cannot do so, first off just in case anybody was wondering you cannot refer to a single object in a namespace. This is being discussed and how to do this. But today you can't- and in this way you want to think of namespaces as you're isolating pieces right namespaces are cheap I had a great conversation with some of the guys from eBay. They just set up a namespace poor user right and you just use the namespace and you don't think about having to do multi-tenancy within a namespace which is way harder.

A

You cannot refer to arbitrary fields in a resource. This is also something worth thinking about adding, but it's also kind of hard right. So you can't say something like this person can create a secret, but out of this type or read secrets, but not of this type.

A

Correct you cannot refer to labels, it's just. It is the top-level resource and that's it or actually and sub resources, as there's a note right there. Just you know not that that is the greatest and greatest thing, but that's sort of the way it is today. So what you can do is you can refer to sub resources. So you can say this person can edit the status of a node, but it can't edit its spec right.

A

That's incredibly useful when you start thinking about all the cool things that come with sub resources, so like pods, I, think proxy is one or pods exec. So when you are setting up these, you also have to whitelist the sub resources and that's intentional, because some of them can be very dangerous.

A

So the are back. Api group has four particular top-level objects: a role, a role, binding cluster role in a cluster role binding. We will get into why there is the duplication in a second, so roles versus role, bindings roles, declare the set of powers right and bindings then come through and bind particular users in contexts to those powers. So you could have a role like admin and then you can later bind them to a namespace or something like that.

A

So this is just the example of what a role looks like so I have a secret reader role. It appropriately can read secrets right, so you see that I've white listed all of the verbs that you're allowed to do. You can also use a star if you want to say I want to give all the verbs to this particular resource. You have to specify the resource in this case secrets, and you have to specify the API group or groups that they were part of in this case, because v1 is weird and special. It's am tshring.

A

Okay, I have my role in my cluster and now I need to bind a user to it right. So this is a role binding. It's a little more complicated, but all it says is that I have some role ref in this case I'm referring to my secret reader and I. This is an alpha, API group, so I think this might have changed. So you should go look up whatever the current documentation is and not trust me and then I have the subjects right. So this is actually where we get to use. All of that information.

A

We tried so hard to pull out of the authentication request right. We I told you all this stuff about how you should embed usernames and x.509 certain whatever, but this is actually where we use that information right, so I want to set up the I want to say that anyone in this particular group has this power.

A

So why the heck do we have two of these things right? Why do we have cluster rolls and rolls so objects and kubernetes can either be named spaced or they're not named space? There is no object that exists in both right. You either define a space for a particular object. You have something like pods is a namespaced. You know thing: they exist in native spaces. Nodes are cluster level they're not named spaced and you're not allowed to have a resource that bleeds between the two so as a hack. Basically, we have two resources.

A

We have a cluster role which exists for the cluster. It is not named spaced and we have roles that exist within particular namespaces. Why would you ever want to use one or the other? Well, so a cluster role is very useful because you can manage one set of roles for your entire cluster that are then used within individual namespaces, whereas roles are actually less common and they're going to be used by within namespaces. So something like I give someone administrative rights in a particular namespace.

A

They can then create roles in that namespace and defer further cluster rule bindings and role. Bindings is the same concept. We need a namespace version of the binding and non time-space version of the binding, and this is where our back gets a little hairy right. So just to walk you through this cluster rule bindings grant a user power throughout the entire cluster right.

A

They can only refer to a cluster role in that respect, so you can give somebody the power within the entire cluster, to be an admin or be a user or be a developer or whatever you choose to name your role role bindings, on the other hand, grant users powers within particular namespaces, and this is pretty powerful.

A

So I would like to give co-worker a the power to administer a particular namespace I create a cluster role, that is the namespace admin and then I give that person a role binding within that namespace to a that allows them to take on that role. They do not have powers to edit that particular thing, but they still have those powers within the namespace, so just as a diagram form, because I love diagrams. What it is is for our left. We have a cluster role binding with a cluster role. I have a cluster role.

A

I grant someone powers within the entire cluster I have a cluster role with a roll binding I have a cluster role that is maintained by a central administrator and then I bind users within namespaces and then I have a role or a role binding, which is I, have actually managed the role and then within a name within the same namespace are going to grant people the powers and the important part is where the role sits right. So where is the role and who can edit? It is actually why this type of setup exists.

A

Cool biggest gotcha of our back role based access control has built-in escalation prevention. So you cannot give someone a role that you do not have the powers that encompass right. If I don't have the ability to read secrets, I am NOT allowed to give anyone the power to read secrets. This is actually built into the storage implementation. So when I do Coop's ETL, you know create this particular role. um It. It doesn't matter how hard I try and how many flags I give to the API or the coupe's ETL to force that particular action.

A

It just will flat out reject it. The current way you get around this for bootstrapping is either two ways you either can use a special flag to give a user the ability to escape this, or you can use the insecure port on your API server to actually get around this, because, if you're using the Institute port you've got here without authentication we're just going to, let you do whatever you want: okay, one-point-six!

A

A

The question was: if you have it set up, do you have to flip a flag to to get around this with the into airport? The answer is no, but that's actually a relative, a new feature, I think that's in one six, but not in like one five or something like that, um so one six, unfortunately portly because I didn't do the work that I need to the are back. Api group is not gonna graduate to beta. It's still an alpha that also lets us have some opportunities to test out. Some of you.

A

Things which is I'm kind of excited about the biggest highlight in one six is that we now have default roles. What this means is that there we're going to be special names that if you meant API, which you mint certificates for like systems couplet or something like that, then the kubernetes api server will just have these default roles that you can use for bootstrapping.

A

So the api server just has the default role of what a couplet is and what access it needs and you just mint in it a x.509 sort for that particular user for your couplets.

A

They are deep down in the api server code. We um we're we're still in freeze. So ideally you know nobody's running one six. Yet I hope so.

A

We still have times a document that but yeah it's right now, they're deep down in the api, so good one, five I'm so lost about what version we are on right now. Yeah, you absolutely right. One size.

A

A

Yeah, okay, so one five um I, it's yeah! It's been a long week, so yeah yeah default roles of the big thing. What's up.

A

The reason the the question was: is this a replacement for the superuser thing and yeah? The superuser thing is super hairy bootstrapping, an API server. Dynamically is hard right. I want to be able to just say my API server comes up with the set of roles that it needs and if you have to coop, CTL create objects somewhere in between that. It's it just complicates the deployment strategy right. So these are really big.

A

In terms of saying these are my immutable declaration of what the API server is, and it just comes up with the things that you need, rather than having to have like a bash script. That's curling default roles into your API server.

A

The question is app.

A

The question is, would you remove the default role after you stepped, and the answer is no. The the default role is not necessarily for it's it's, so you can statically declare and say something like this is the Kubla to power. It also allows us to think about giving you suggestions and saying hey for kubernetes 1:5.

A

These are everything that the couplet needs to access right, and we know this better than you, because we have tests that someone is going to break right and if you know new roles are added, we have to figure out migration strategies, but that's just another can of worms. But the idea is: let's let us declare the things that you need and then we can work from there cool there's some other plugins there's a web hook.

A

You can use it, there's actually I'm blanking on the name, but one of the guys I've actually seen a really cool web hook, implementation open sourced recently. So if you're in here, you should raise your hand and I can call you out but huh Mike from Pearson yeah yeah. He he had a really cool implementation of this using the web book, there's also an API policy file.

A

This is this is actually what most people are using today, and this is really useful for bootstrapping, but we sort of see our back as the default way that you want to go later on, because again, policy is something that you want to control dynamically at some points, I'm, not saying that there aren't static things, but you know we would like that eventually cool.

A

So now for anybody who knows all this stuff, this is the slightly less boring part, so I'm going to talk about decks. So decks is an open source project that I maintain over at core OS. What Dex is it's? This thing called an open, ID connect server, so it implements a protocol called Open, ID Connect, which I'm going to go into.

A

This is one of the authentication protocols supported by kubernetes, so as actually our way of hooking into the authentication point in kubernetes and the important part about Dex is that it actually does this thing: it federates to other identity providers to actually log you in and we'll go in what the implications of that are in a second so and today, I'm here to announce the fact that we've revamped the whole project and in releasing a major version. So we actually, this has I, think 999 stars on github.

A

So anybody who wants to give us that thousand do it or you know, look at the project first and they give us the star.

A

So before we go into the all the v-2 stuff I'm going to just try to briefly explain open ID connect in five minutes: okay, open ID, Connect is just a lot. You all know a lot or you know you pretended to know uh for jobs. That's great me too. So the way that two works and the way that Open ID Connect works is that you have some identity provider in this case Dex or you know, for Facebook or Google or github or whatever. um What.

A

Can we tweet that? Thank you awesome. So a lot you go to an application that application redirects you to the identity provider that it won't slug you in with it, has some special URL parameters that it uses to do this. But essentially you go to an app. You get redirected the identity, the identity provider that identity provider logs you in cool. So this is the same thing with Dex. You go to a client application, client application, redirects you to Dex Dex, then logs you in and redirects you back to the app with a little code.

A

The app takes that code goes to the identity provider that identity provider returns. This thing called an access token right. So if you want to post on someone's Facebook wall, this is what you do right. I write, an application that does this dance I exchange the code with Facebook to get an access token that I can use with Facebook to talk to to talk to like post on their wall or something like that. Programmatically Open, ID Connect expands the response of the token with one particular field called an ID token.

A

So this is a token response from open, ID connect. It should look very similar because it is a de WT right. It's the same thing that the bear it's the same, encoding that the bearer token used. This happens to be a JWT signed by DX. That JWT is again header with some information about like what key was used to sign it, its payload and a signature.

A

This is the payload and this is a well defined payload, except for one claim that I will explain in a bit, so they have the issuer in this case Dex they have the subject, which is a unique identifier for that user, and you have very convenient things like email. This is just a standard, it's written great and the problem with those access tokens that you get back from Facebook. Is that they're all completely opaque? You can't look at the access token and get some information.

A

If you want to authenticate somebody with Facebook, you have to write to their API and figure it out for open ID connect, because this is a standard. You parse the data beauty after you verify that it was signed by Dex. You look at it and you get the email from the user like that right and you it's just a standard, so it will work with any other open, ID connect provider. Dex adds one particular claim that we like groups right. You skin, o fella, pers developers.

A

Developer, yeah, okay, yeah no go for there go I need to update my slides online, all right cool so because it is a standard. I can go ahead and take that token and authenticate with the API server right, you can actually do this with a few other providers. A notable one is AWS single token SDS I, don't I figure what that stands for, and so on and so forth.

A

So I can login to decks and then be authenticated with the API server, which is kind of cool, and then we go back to decks logs you in through other things right. It does not log you in through Dex Dex has a user database for bootstrapping, but primarily its goal is to log you in through some other provider that it supports. So you can log in through github. You can log in through Google.

A

You can log in through your LDAP server and Dex will figure out how to log you into the kubernetes cluster Dex has some really cool features. It has automatic signing key rotation, there's, revocation just because it's ooofff lots of login options. Dex v2 was a complete rewrite of Dex. We tried to make it dramatically simpler to deploy. It is now a single scalable binary and we rework the storage layer.

A

An important addition to the storage later layer is that we can now store a little bit of our state, like refresh tokens like nonces, to prevent replays in the kubernetes api server right, so I can actually store all the state for Dex in the kubernetes api server and you can run natively on top of criminalities. Some might say that's an abuse of third-party resources. It may be right. We probably want to switch over to some other.

A

You know: kubernetes native storage, we're really interested about the SED operator work, but for now this at least gets us to where we need to be so runs. Natively in your cluster can all sent a cait through backends, like google github, so on and so forth. Demo time cool. So I have like four minutes to do this demo, so we're gonna have a lot of fun. Okay, so I have a cluster running up.

A

A

Cool I have a cluster running. This is using the chorus bare-metal repo shout out to Dalton Hubbell, and it is. It has some authorization rules that I set up. It also has done the appropriate API server, dance, three to add flags for OID, C cool, so pointing to Dex. There's some example app. This is the client that you must log into. There is a see a file and username claim and so on and so forth. I here.

A

Just earned it keeps new get deployments I.

A

Have a Dex running all Dex is: is some pods running config maps with a config map mount it in that config map is super fancy. It has things like where it runs. I, don't know it also has like connectors. So connectors are the way we log you in through another thing, as you can see, I'm about to log into github.

A

So in this case, I've configured it to talk to github and I actually have configured it to pull the teams from the kubernetes organization right. So this is how we populate groups of github. We have other strategies for other identity providers, we're also working on this cool. So what do I need to do to actually log in I need to run a client app seems pretty reasonable, I give it the issuer, which is Dex only and then give it a CA cool.

A

So the way that you log in to any identity provider again, is that you log in through an application that redirects you they're, not localhost, liberal those, five or five right in this case I'm, going to give an extra scope of groups I log in and I get to Dex. This is Dex I'm going to choose to log in through github it's going to go to github and I've already authenticated, so it didn't prompt me right and importantly, this is the de WT that we can use to authenticate with our cluster.

A

This is the fact that I'm part of sig off and future maintainer, so we've actually pulled groups there and then I can go ahead.

A

Documents. Sorry I need to look. This up token equals that really long bearer token and I am now authenticated with kubernetes. You can clapped-out.

A

Three minutes for questions: you must go up there to ask a question because he has a mic: yeah go for it. You can just go up there. Yeah.

B

So you're on a really great path, already doing the open ID connect when you start talking a lot of enterprise customers, I work on a different open-source project and you're on a very similar path that we were on and then you're going to realize that customers are asking for being able to work with multiple LDAP Sande active directories being able to do sam'l assertions. In addition, as the other way of doing federated identity and then multi-factor off.

B

So have you started thinking about all those things that might be coming down the path down the pipe because they come really quickly from the really demanding customers yeah.

A

Absolutely I mean we are always trying to add new connectors. You can have multiples of these. So if you want to log in with different LDAP servers, that's already a thing I mean ultimately, Dex is a really simple project. Right. It's a it's an OID, C server! It's like you know a few hundred lines of code does all the things and then the biggest work it for us is just adding connectors and actually authenticate you so yeah I mean this is why we built it actually is exactly for this particular type of use cases. A.

C

um About a month ago, there were some really detailed documents in the Dex repo regarding various connectors and those are gone now. Yeah.

A

I'm so sorry, oh I've been rushing to so you know two points I've been rushing to try to get the repo switched over to v2 for this demo. I apologize for doing a little bit of marketing base developing but yeah I mean we're going to try to add those back in the new implementations are actually a little bit different and we're still trying to iron them out. Like I, don't know. If that's the way we want to get groups from github, so we don't necessarily want to publish detailed documentation.

A

Quite yet it's in beta for for right now or what we're calling beta. So as we get to 2.0, we will add that it will be mandated to add that documentation before we do that. So I got an I apologize. Okay and.

C

Then a second question, since no one else is here: um I noticed that all the example Doc's regarding authorization show just a single wild card is working. Can you embed a asterisk in a path for like shell-like, globbing or regex like globbing, so.

A

There are these things called non resource, URLs which I didn't go into. You can do that for those you can not do to the best of my knowledge. You can't do that for sub resources, so.

C

You can't do that for namespaces or something like that. uh Oh.

A

So you can use you can use a an asterisk for I. Give sorry for namespaces, potentially.

C

If you have like a number of namespaces, let's say you have several production namespaces right: they all start with prod, whatever can do prod star and have that work.

A

So the only way to do that to refer to multiple namespaces would actually be have cluster roll binding, because that's the the tappable thing that has no concept of a namespace right, so it only gives total access or no access at all. The way you would have to do that is. We have to create individual ones and you'd probably write a controller to do that.

A

Yeah. You can do the web book, I mean you could I mean. Realistically you could write a third-party resource on a controller right, so I write a third party resource that you know declares right where I can do something like that and then I have a controller that spawns off the appropriate role. Bindings would be another way to do it. Sick.

A

Ready you just want to talk after okay cool what thanks everybody for coming here.