 Hello, everyone, Nihao Sanghai. So today, we'll be having a small talk on understanding how to secure Kubernetes using Webhook as well as Keystone. Myself, Somita Kuntia, I am a part of Erikson India, working as a solution architect. We work as a part of community contributors to the ASC project. I have with myself, Pradeep. Hello, everyone. This is Pradeep here. I also work as a solution architect at Erikson India, and I also contribute to the ASC community. Thank you, Pradeep. So let's move on. Are we having a technical glitch here? OK. So what we're going to talk today. So Azenda is to have to understand a little bit of, why do you need access control in Kubernetes API? And then we'll move on to have an overview of some Kubernetes admin control, and then understand what is the Webhook mode, how to do that, and how to configure a Keystone authenticator, and then the benefits of that. So let's move on. And when you talk about access control, why it is required. So you know that the KubeLate, it exposes, it provides the STTPS endpoints, which gives you access to your nodes and containers, and you have a lot of powerful control over that. But when you have that, you have to be responsible when who can access and what can be accessed, right? So that is one of the needs for us to ensure that there is a proper access control is there. So either you can give access for a specific operation to everybody for all the resources we have, objects we have, or you can not allow them. But doing that, it will lose the flexibility what is required for the Kubernetes API, or the APIs which exposes. So what is necessary is to have something which provides a good access control at a granular level where you can decide the privileges, you can decide the permissions for a user that what they can access, what they cannot access. For example, namespace, ports, or any other resources, and what kind of operations they can do over it. So that is why it is imminent to have access control permissions, which separates the responsibility and depending on the action a client might perform. Apart from the access controls, the granularity we need to have, we also need to have an authentication mechanism. The Kubernetes comes in multiple ways, you can authenticate, but keystones, if you can leverage keystone itself, it has a lot of advantages that we can leverage apart from what Kubernetes provides by default. One of the biggest advantages we have is the rotating infrastructure credentials. So we can have keystone to rotate your tokens periodically to make it more secure. And the other part is that, suppose you have an open stack infrastructure already been using, you have a user base to that, and you also having a Kubernetes cluster, maybe on the top of the open stack running on it, and you want to leverage the same tenant users so that you don't have to create a duplicate users for Kubernetes. And then, like example, having an existing LDAP back in for the keystone or something, this gives you a good opportunity to leverage that having the same keystone users can be used as a Kubernetes user to provide an access grant. So that is what we'll talk about two things. One is having an overview for access control, for privilege, and then keystone as an authentication mechanism. Moving on to the next, we have a high level overview, how it works and how the integration happens. As you can see, there is a CUBE CTL client. So this is all the external communication that happens to the Kubernetes. You can see that. The first thing the CUBE CTL clients do is that it can access from version 1.8.0. We have the CUBE CTL provides option to integrate the OpenStack environment variables or a keystone user environment variables. It can pulse it from there. It can request keystone to get the token out of it. So once you get back the token, the CUBE CTL client, then again passes as part of the request, the token. Instead of credentials, it passes the tokens to the Webhook API server. Now, when you talk about Webhook API servers, it's considered of a two part. You can see that it's like a CUBE API server containers running as well as a Webhook container running along with the policies. So CUBE API server is the one who takes it and then it bypasses it to your keystone to validate. Sorry, once it passes to the Webhook server, which again passes on the same token to the keystone to get it validated. Whether that token is valid or not, and once it's validated back, the Webhook takes care of requesting for the RBAC policies that it has been defined, and then depending on the state of the request, it saves back to the H3D, the store that we have for the Kubernetes users. So this is a very high level overview. Let's move on to have little more details of the configuration, and my colleague Pradeep will give a view on that. Thanks, Pradeep, what do you want? Thanks, Amitra. So yeah, this gives you an overview. So this basically has two parts, if you see here. One is the client part, and the other one is the server part. So we need to configure the Webhook with the keystone in order for it to authenticate and authorize any user who is trying to access any of the resources on the pods on the Kubernetes cluster. So first, let's see how you can do on the server side, and then we'll see at the client side. So basically, we all know about the Kubernetes Admission Controller. So Admission Controller is the one which is responsible for authenticating, authorizing, and also providing access to various resources on the Kubernetes cluster. So first thing that we will have to do is add this Webhook filter in the Admission Controller as part of your configuration. So once you add this, so the requests that are coming to the Kube API server will automatically get routed to the Webhook, and via the Webhook, you can actually configure Keystone which will do the authentication and authorization for you. So here if you see, there are two parts again to it in the Admission Controller, so which is the mutating admission and the validating admission. The mutating admission is basically an interceptor. So it just intercepts any request that comes in, ensures that it is valid, and if it is valid, then it sends you the validation where it validates the token, whether it's a valid user and also has a valid role, and then it sends the response back to the client. So this is just an example of, that was on the server part. So this is an example config file on the client side. So you must have all configured the kubectl config on the dot kube slash config file. So this is how you would need to make the modifications. So if you see the highlighted one, which is basically doing the exec, and this is the authenticator that is basically used in order to authenticate against the Keystone. So you will need to add this section and you'll need to create a context, and once you create the context, you can route all the calls to the Webhook API server. The server that I'm showing there on the top is basically a Webhook API server that I'm pointing to. So this config file is for the versions V11 and above. So for the clients, for people who are using clients older than V1.1, V1.11 will have to make a slight modification. If you look at the end, you will have to use just a second. Probably it's on the next slide. I'll just show, I'll go back to that. So this basically showing the policy configuration. So now we know that in order to do the RBAC configuration on the Webhook, you'll need to define the roles and those roles have to be existing on the Webhook server. Once the Keystone, let's say we have an admin role or a non-admin role on Keystone. So the roles have to be defined and the actions for that particular role also has to be defined as to whether an admin or a non-admin user can access some of the operations, some of the resources in the Kubernetes cluster and whether he should be restricted to access some of the clusters as well. So this defines all the actions. If you see there, the verbs give you whether you can do a Qubectl, get pods, get list pods, watch operation and so on. And it is given to only the default namespace and only an admin or a member role can actually do it. So if you don't want to give the access, you can probably restrict it in this policy file. So this is the one I was talking about. So this is the older client on the, for the older clients, basically we 1.8 to 1.10. And the slight modification if you see in the bottom of the slide, the auth provider instead of the exec command that you saw earlier, and you'll need to give the name as OpenStack. So OpenStack is basically a name that I'm giving for my deployment. So yeah, so we've seen how we can configure the client and the server in order to ensure that you use Webhook and Keystone. The, what are the, I mean, why would I really want to do it? What are the benefits? So we all know that Keystone gives you so many benefits like the token rotation, the, I mean, the token can be rotated. If you want to add a new user with a service account, then you can actually add him easily without really having to change any of the cluster configuration. So you can just add him on the LDAP. If you're using an LDAP user, then just add that user on the LDAP and you should be able to quickly have him access the cluster. And this also ensures that some of the, some parts of the cluster are inaccessible if you want only to give some, some access privileges to, to some resources. Like for example, you do not want somebody to do some destructive operations on Kubernetes, right? So you can just give a get or read only access to some of the parts and other resources. So that's, that's basically the use. And obviously you can also, you can also change rules in case if you want to for some of the, I mean, on the fly you can actually do a config map, do a get config map, get the config map and then apply the config map back so that you can change the policies for a particular user. So all those things can be done without really modifying the code. So that, those are the benefits that you're getting by, by doing the authentication authorization with Webhook and Keystone. So these are the references in case if anybody of you are interested to go through this and get more information, please go through these links. And obviously we'll be reachable on IRC or Slack so you can always reach out to us as well. Thank you.