 I'm sorry for the delay, so let's get started. So in this session, we're going to talk about multi-tendency support with RBAC and Namespace. My name is Michael, and this is Fred, and we're working on a team to bring Kubernetes cluster to vSphere environment. We also have a team working on upstream in terms of various areas, in terms of clustering, scheduling, and the various areas. Okay. So what we're going to cover in this session is, we're going to talk about the basic namespace, how can namespace offer isolations between different users, and then how can you use RBAC to enforce policies and permissions to provide additional controls for those users. Then we're going to talk about how do you put namespace and RBAC together, so to offer multi-tendency to the users with some level of control. We certainly understand that there is a way for user to create multiple clusters to offer that level of isolation, but you're going to essentially spending a lot of resources, you're going to have a lot of cluster to manage, and that's not ideal for most of the environment. Therefore, when we talk about multi-tendency here, we're really talking about multi-tendency within a single cluster, and Fred is going to follow up with that demo. So this is a pretty general environment. You have an IES under the cover, it can be AWS, it can be a vSphere, it can be Google Clouds. So then you put Kubernetes environment on top, and your application is running on top. The identity management for the most part is an external component of it, and then you use different ways to hook up your identity management to it, and it will be ideal that your IES hookup, your user from your IES can be translated into the Kubernetes layer, and that we believe have multiple ways you can integrate them together. It's possible. Okay, we create a couple personas for our use case. So for most of you guys, if you start working on Kubernetes a year ago, your task is a lot of things you need to do as an application developer. So you not only need to worry about how do you write your application, you also need to worry about how to monitoring, scale your cluster, you also have to worry about how to create your cluster, and it does a lot of cluster management. As time goes on, we believe there's additional persona that will be created in the future, or it's already starting form, and so basically we're thinking about there can be a dev-op admin person who can help you to help the developers to kind of scale up, scale down the cluster, and kind of monitoring the cluster, and this person can be very much on the same application team, but just have a little bit additional special task. But the most important part we think is going to be the cluster creation, the cluster management, is going to be outsourced to a cloud admin, right? A specialized cloud admin to help you create the cluster, but also does a lot of user level management. And I think if you go to some of the sessions, one of the sessions talking about is how do you increase your team's efficiency if your application team tried to devop applications? One of the best practice is essentially outsource your cluster, your user management, to an administrator team to help you to manage that. So that's what we're talking about here. And Fred is going to talk about the remaining. Okay, thanks Michael for the introduction, the problem, right? So I'm an engineer and try to solve that problem, of course. So before actually I can go to two actually topics I'm actually covered. One's actually, you know, what, like, definitely I'm using Outback and namespace to solve the multi-dendency problem. And also actually I would talk about, you know, the models we support and, you know, some model actually we will support in the future. So let's talk about the Kubernetes namespace and Outback, how many actually are actively using Kubernetes right now? Wow, there's a lot of people, good. I probably fight through it because different audiences, I need to introduce some terminology. So basically I'm just actually introducing some terminology, CS. I don't have to go through these slides, you probably know what Kubernetes, just an open source platform, decide to automate, deploying, scaling, and operating application content. So I put the link there, if you're not familiar, just go to the link and look it up. I think you will be excited to read that. The next thing is actually, the reason I have to just roughly go through the concept because that's actually how I use the Outback namespace actually to, you know, support the multi-dendency. So in the Kubernetes terminology, a node is just like either a physical machine or just a virtual machines, right? And namespace is, you know, it's a virtual cluster, actually provides relations of resources. We leave namespaces because yes, basically that's how we can do the multi-dendency. One tenants actually cannot see the other tenants resources. Port, unit of deployment, a single instance of application in Kubernetes, one or more containers, right? And surface is basically the abstraction, how you actually expose your surfaces to the outside, right? And of course, Outback is the root-based SS control, you know, we are using to do the enforcement, right? Okay, so I'm just actually quickly going through that. So that's the way actually I look at it, right? Kubernetes actually is kind of like cloud platform neutral. So it doesn't actually really dictate a particular security model. That's good and bad, I mean, but that's actually what it is at least for now. There's two category of users, right? So it's actually, there's a service account users. So managed by Kubernetes cells, you actually go to Kubernetes to create the users. And then also, there's normal user, actually managed by outside. Managed by outside means actually it's like, okay, you may actually have a database somewhere, or you may actually have IDM, or you may have, you know, LDAP, whatever, right? So the user is managed by outside, that's what I mean. Nice thing about that is actually, Kubernetes actually allow you to extend the authentication plugin, and then authorization plugin. So actually you can basically connect that to, you know, outside sources to do the authorization and authentication. Okay, so inside the toolbox, right? So what I can use to do my job, right? So let's take a look at the namespace. Like, basically this slide just showed that, you know, how the isolation can happen, right? So in Kubernetes actually, you will always create the default namespace for you. In this case, I simplify it, right? There's more different type of resources actually in the namespace. I only actually talk about a port and services here because just, you know, a typical application actually lead to a container to run your, what? A port to run your container or your application, right? And then you use services to export it. That's one way services, right? So I'm just showing you like that three namespaces. Actually the port actually is different namespaces. So it's isolated, you know, basically the one port, if you're within a namespace, you can see the port in the other namespace, okay? So that's the foundation, you know, the isolation I need to provide the user the multi-tenancy. Okay, so for our back, just again touch about the concept again. So basically the outback, the way it's set up is actually there based on rules, right? And then there's two types of row. They use the object called row. Like there's a cluster row and row and I'm actually going to give some example later, right? And then I'm to granting a permission, actually the way it works, the outback in Kubernetes is actually you do either cluster row binding or row binding, right? Row binding is actually for a particular namespace and then, you know, cluster row binding is actually for cluster one and all namespaces. Yes. It's a separate thing. This is actually Kubernetes. What Kubernetes provide, okay? So, yeah. Of course, I have talked about subject. Basically, you know, when you grant a permission, you grant to a subject. The subject actually can be a user, a group and a service account, right? Okay. So I'm just actually quickly go through the things I actually can define, right? In the cluster row, of course, you're from the Kubernetes. Basically, I just do a dump using the output, right? Dumping the object itself. So the, so they have a kind. Basically, it's the cluster row and then API version, you know, what API version you're using that to talk to the Kubernetes to retrieve our objects. Metadata, you need to specify name. So this is actually no reader and if you read the rules below, actually, it will make more sense, right? It actually don't limit it to any API groups. The resources, actually, we are interested to specify. It's just the notes, right? And then basically the action you can do is either get, watch and list. So that's why it's a no reader. So actually, that's how you control the, you know, what a particular subject can do. So then actually we go to the row. The only thing is actually make the differences is actually the row actually will ask you to specify namespace as well. In here, I'm just saying that using default and then you look at the rules, it's very similar. I don't specify particular API groups, right? But the resources in the process actually inside the namespace, right? So actually I say, well, okay, inside that default namespace, you can do these words like get, watch, list on the pods. So basically against, that's why it's called pod reader row in this case, right? So the next thing is actually I have is cluster row binding, right? So remember I said that, you know, in order to grant permission, actually you're using row binding to doing that. In this case, right? If you go to the, like the first thing, again it's the kite typical, right? I mean all the objects has this kite. API version, let's forget that. The name is actually where you specify the row binding name and then you now actually refer to the subject. Subject right now is the kites group. I'm actually saying that all manager group can do the following, right? So what the following can do is the rule reference and saying that, hey, the kites cluster row and then, you know, that's the one I specify, you know, in previously the load reader. So basically all the group manager can read the notes. Okay, so let me quickly go to the row binding as well. Again, this time actually I basically grant a user called James, right? If you'll go down to the subject. And now of course I missed something it's actually because it's this row binding it's actually it's particularly in space. So I'm actually specify name space default. And then, you know, the user actually is James actually he can read the ports. So that's actually the outback, you know, give me the graph, the granular control like who can do what, right? So that's pretty much actually what we build on top of it. Okay. Yes, yes. I have a problem when we connected to LDAP and we have issues. So the authentication actually works but when it coming back is actually is a lowercase. So we ask the customer to basically saying that, sorry, you have to, you know, when you specify the, going through our interface you have to specify the user in lowercase. That's the temporary get around right now. We will address that probably later. Yeah. You can add all the user and you can also group them, right? So we support like, you know, group user and surface account. So actually you can like, for example, the exam the PV example of the group is the manager it's not a single person, right? Okay. So the other way you can do is you can also link you to your backend LDAP, right? So if you link to and to your backend LDAP all the users are automatically put in. Right. If you guys don't mind, I'm just like, do a time check. I probably will defer the question at the end or you know, but let me finish the presentation. So I quickly go through like the flow, right? I mean, probably curious actually how, you know, the flow works. So when a request coming, if you look at from the left-hand side, right? When a request coming to the Kubernetes API server, right? So actually it first actually saying that, hey, you know make sure that's user is a valid user, right? So actually it go to KX authentication plugin. You can specify your own plugin, right? So let's make sure that the user is authenticated. It's actually what we know that who he is, right? And then the next thing is actually based on the so actually you're based on operation. You will ask the, oh, sorry, actually I skipped too fast. I'm actually at the authentication in this case actually go to the IDM. Right, so it doesn't have to be like a local database file, right? So actually can go to IDM and then, you know, saying that, okay, good, you know, this user is authenticated, right? The next thing is actually based on the operation, right? You will actually defer to the KX of authorization plugin, right? So you will actually make sure that, okay, that person can be authorized to do that operation. And after that, so we can process the request and return the result. So I'm actually pretty generic, you know, basically what's Kubernetes does, but it does help me to be able to create a multi-density environment in our case. Okay, so I'm talking about the user security model we support and my support in the futures. But again, a lot of time we use a model really depends on your organization, right? I mean, actually, so, but this is actually we support so far, okay? So just quickly refresh the screen. I'm not going to go through it because Michael actually gave a very good description already. So developer DevOps is actually in the application development team. So basically they are developer in a sense, right? And then the cloud mean is kind of like two roles, but we actually have customers really warm to actually have some, basically I mean want to delegate some privilege to the, but particularly developer. So actually like Michael mentioned, you know, you can scale up or scale down the cluster or do a bit more like, you know, things look at the law, things like that. Okay, so this is the first model. So we call it exclusive cluster. Let me explain using the way I interpreted it, okay? The exclusive cluster here means is actually, I have a cluster is exclusive use by a group of user. So that's exclusive mean. So, okay, so in this case it's like, it's a simplest model. It's pretty much like, you know, when you first time, you know, create your cluster, right? You just let your coworker to use it, right? It's a single tendency, right? What I did here also is actually basically collapse the roles of DevOps and a mean and developer. So no such a things actually, they just all develop it. And the cloud mean has full control, right? Have user access, have cluster resources. Any authorization user can create a namespace and just like probably when you first time create the Kubernetes cluster, right? And all namespace are resource are visible to all authorized user. It means actually if you allow your coworker to use your cluster, basically he or she can delete your namespace as well. Because the cluster resource is invisible to all the users. So in this case, again, it's only the mean actually can do it. So this is a bit more supporting the different, basically DevOps mean, you know, model, right? So the light blue colors is the things actually got changed from the exclusive cluster itself. So you actually have the two distinct roles now. We preserve that, right? And the cloud, the cloud mean actually then dedicate some controls to the DevOps, right? And then basically the DevOps can do some means job like, you know, in the cluster level resources, right? And the last thing is actually the cluster resources, the color change, the change once is, the resource are not visible to all authorized developers. It's the same, actually developers still actually bound by that same rule. So let's go to the share cluster and then we will do the demo. Hopefully it's more interesting. The share cluster, right? So share cluster, the idea is actually really the support the multi-tenancy within the cluster, okay? So the way you do is, against this model is simplified model, we collapse the DevOps mean and the developer, right? And then basically against kind of me as a full control. So if you look at the right diagram, the pictures on the right, right? So what it does is actually we assign the user within the namespace. So we use the namespace to isolate, you know, what they can do, right? What resource actually they can see. So that's actually the model is, and also of course is they are just developer, they cannot, you know, see the cluster resource as user. So let's do the... Actually, so the picture might be a little bit confusing. What we mean by each column is it's a different set of development teams that they can use different set of namespace, but they cannot see each other's namespace. So that's the difference. So it's not the same two developer go to different namespace. Yeah, it's a persona, it's not like, it's not the user, they can, but you know, it depends on your, treat it as more like a persona than a role. Okay, so the next one is actually against is, you know, give the distinguish no role again. So it's not much different from, you know, well, I mean, is the main differences is actually against the developer means actually has a bit more privilege to deal with the cluster level stuff, right? Look at the dashboard, look at the log, right? I mean scale up down the cluster. Okay, so let's do the demo. So five, 10, right? We are, okay, so we have 10 minutes to do the demo. Okay, sorry, I bit rushed, but just wanted, we can do the demo. Hope, okay, still up, that's nice. So, oops, sorry, okay, oh, the screens, the screens, okay, it's very interesting. So let me bring up the, okay. So, this is our product implement the two cluster roles. Okay, oh, I can, you can see, okay, new challenge. Sorry, my voice is probably too loud. Can you see, okay, perfect, right? So, this is the product we create to support the exclusive cluster and then a shared cluster without a variation. So, the basic model, right? I already create two cluster, but I just want to show you that, you know, when, you know, how do you create a cluster? That's helped to, you know, doing the demonstration. So, let's pretend I'm actually creating one, I'm not gonna create one, because it takes some time, because I have 10 minutes, less than 10 minutes left. Okay, so, okay, so let me try to pretend I'm creating exclusive cluster, so actually I can, you know, continue to do my demo. So, first, actually, I pick the provider, right? Provider in the sense is, you know, the, treat as the IAS we talk about. So, it's just an object, you know, presented in there. So, I pick the provider, IAS, right? And then, I actually just quickly go through it, I can specify, like, the cluster name, right? So, let's say I just call it exclusive cluster. So, let's say I have three masternodes, three workernodes, and then that's by the DNS. So, actually, I can access outside. And then you have the choice. Yeah, yes, thank you. So, by default, actually, it's exclusive cluster. So, actually, I pick the exclusive cluster in this case. So, next thing is actually, as administrator, so I would see, you know, a bunch of users, right? So, I can pick the user I would like to add, you know, allow to access the cluster. So, in this case, actually, let's say I pick the deaf one, the user, I'm only allowed him to do it, but for the deaf two, I didn't actually check it. So, just next, right, and then you just kick finish, you will try to create a cluster. So, I'm not gonna create this, I'll just close this window, and then I already create exclusive cluster for this. So, actually, just quickly go into there, look at the user and group. So, the user is already, like, what I try to create, right, is actually the development one user is there. Okay, so, let's do a demo. I messed up the window a little bit, so I probably, so, this is the deaf one user, like, so make sure that one user lock into that, right? So, if we just do a group control, right? Yeah, you can see all the namespace, well, by default, actually, the group name actually will create some, the default namespace, and then some, see some level namespace as well. Okay, so, the user can see all the namespace, and the user also can create namespace. Okay, so, let's say I create the namespace deaf, right? So, it's good, right? So, the user can basically, just like a developer, set up their own, you know, a Kubernetes cluster, actually can create namespace, and do whatever basically he or she wants, right? And then, let me find the deaf two user, in this case. Now, this deaf four, okay, this deaf two. So, deaf two users say, well, I want to actually assess your Kubernetes cluster as well, so let's actually doing that, right? So, when Fred created the cluster, he only add deaf one to the cluster. He never add deaf two user to his cluster, so that's why. So, it was actually coming back saying that, let me move the screen a bit center. Basically, there's no policy allow you doing that. So, basically, that's, you know, to demonstrate how the exclusive cluster can do, right? I mean, the user actually using the exclusive cluster. So, just want to show that, actually, just show that we actually create the namespace successfully, right? Okay, so, you can see the deaf one is there, okay? So, this good, right? So, exclusive cluster, right? Can use by a group of people, right? And then, they can actually create namespace extra like that, right? And then, let's go to the, as a second model, is the share namespace. So, I'm actually going through the, just roughly going through the equation again. So, the difference is actually very similar. I can quickly go through that, right? So, actually, I see like that. Actually, let's say, I'm say share cluster, right? And then, I say, three, three, okay. And then, I have to select the share cluster. So, the things change on the left-hand side is actually, that's the namespace. Actually, it used to be user and groups, but now I actually show you the namespace. If I click next, okay. So, it asked me to actually, you know, do you want to create namespace, right? So, actually, I say, well, sure, I want to create that namespace. And then, this case, I allow the dev3 to use it, okay? So, I just say, next, it's very similar. I'm not going to create it again, just like the last one, but I show you the one actually I already pick create, in this case, right? So, in the share cluster, you see the tabs a little bit different. For the exclusive one, you see the user and groups. Here, actually, as you saw the namespace, I click the namespace. I create a namespace, okay. I create a namespace called dev, right? And then, you know, the only user there is dev3, okay? So, let's switch to the dev3. Okay, so this is dev3, okay? So, dev3 is if, so, okay. So, let's show what he or she can do, right? The dev3, right? So, you've actually tried to get ports, right? We've seen the namespace because, actually, he assigned to the dev, right? So, I haven't created a resource, but basically just say, hey, no resource right now. Because I actually didn't create any applications, or I should say, right? So, there's no parts actually created, but it does actually show it works, right? And then, if I try to do the same thing like dev1 do, let me try to create a namespace dev3, right, whatever, okay? So, you would say, you won't allow to do it because this is multi-tenancy environment, you cannot actually do the namespace yourself, okay? And the, of course, same thing. So, I want to actually quickly go through the dev4, right? And the expectation is he cannot do, he cannot even see the namespace, right? So, if I do a coupon, I get ports, right? Okay, namespace, dev, you will say no policy, yeah, yeah. So, basically show you, use Outback namespace, actually create two type of cluster. One actually is a cluster can use by a group of people. And then also, the other clusters actually can support multi-tenancy, the user actually belongs to attendance, cannot see the other tenants, okay? Sorry? Sure, sure, sure, sure, okay, yeah. So, you would say, okay, get, you would say no policy, right? Because there's no policy allow you to do that, okay? So, that's our back policy under the cover to control the namespace. The Kubernetes Outback, I'm gonna get very specific, so yeah. Thank you, Fred. So, I'm gonna skip all the other slides, go to the summary slides. Yeah, I have a whole bunch of slides, just in case like my life table won't work. You'll never know the wifi will work. So, Fred did a good job to create the, essentially, to create multi-tenancy with the namespace and the RBAC concept with the pure Kubernetes namespace and RBAC policy, right? So, if you go to the multi-tenancy talk this afternoon, there are many other things. Multi-tenancy, SIG, this afternoon, there are many other things the group is talking about. They're talking about DNS separation, CODA separation, and then there's a potential of the network isolation. So, we are working on those things and eventually we should be able to offer that level in the future, right? So, for reference, we put down the link to the RBAC, the product we create to, so you can take a look at the product if you want to give it a shot, and then we are also hiring for VR. So, that's it, that's all we have. Any questions? Thank you, go ahead. Mapping user role actually depends on the authentication plugin, right? Depends on what authentication plugin. Of course, in our case, we're using OpenStack in that particular implementation. So, yeah. Oh, sorry. Correct me if I didn't actually say the question already. The question is, can you actually handle the mic? Oh, yeah, yeah, yeah. Maybe actually, I'll ask the question again. Sorry, my bad. Since Kubernetes doesn't come by default with an authentication solution, I was wondering which one you used, and once you get a username, how you mapped the user to a specific role? Yeah, we actually using the OpenStack authentication in this case, yes. So, basically, we have a plugin on the backend, so to pull the user from all the backend and all the app, and then when we pull them in, we just map them there. We don't do anything filtering or anything, we just pull them in, that's all. The bridge, the plugin, it doesn't really matter, just we have a plugin to pull out the user. So, if you want to go to detail, basically, the authentication plugin will implement a few things, right? So, actually, once you authenticate, it will actually put the user and role in the context. So then, actually, when you pass to the Outback, Outback will basically pick up the user and group whatever in the context, and then you do further processing. Any other questions? Yeah, that's the limitation right now. Basically, again, the model we have against this is have limitation, right? Right now, we don't. Either you actually have to limit by name space, there's only two models, it's bipolar, right? Either actually you are bound by one single name space, or actually you will assign to a cluster to create any name space you want. I understand, sometimes you want to actually delegate to some user, actually can create extra name space. We kind of touch about that. We introduced the depth of a mean, right? So, a person actually can have a developer have a bit higher, you know, privilege to doing that, but we are not implementing that in this release. Right, so, well, we are talking something about future, right? So, okay, it's not that. We haven't implemented that. So, remember, Michael said it's actually per cluster. So, again, it's actually the authentication part is, if you look at that, very simple, right? Well, I'm talking about the isolation of resource per user. I'm not even touching the network, you know, it's the story things, actually, let's be honest, I'm actually not covered it. But let's say using the Outback, let's play with the Outback again, right? So, what you need to do is actually the authentication, right, you have to come in to some source, right? So, let's say, if you can aggregate that, right? And basically, you know that the user coming in is the same user, right? So, what you need to do is actually you have to push down the Outback rules to all the cluster, right? That's one way to do that if you're using Outback. But, you know, if you go through some other talks, there's many different ways to enforce it, yeah. If you have detailed question, I can answer it, but given the time, I think, I mean, we can answer a question here. So, thank you everyone to be here. Thank you. Okay, thanks.