 I am working as a member of technical staff at Caston by Veeam. So today we are going to talk about securing Kubernetes clusters with OIDC. So here is the brief agenda that I am going to cover today. So first of all, we will talk about challenges in Kubernetes related to authentication. Then we will set some concepts on OIDC, then we will see one of the common workflow for OIDC and then we will see how Kubernetes integrates with OIDC and then we will wrap up the session by talking about some benefits and best practices of using OIDC. Challenges in Kubernetes related to authentication. So in Kubernetes we do have a concepts of user account but it does not provide a single building mechanism to authenticate those accounts. So there are some of the basic mechanism but they do have drawbacks. So we will see how OIDC overcomes all of those. So the first method, the basic authentication method is static password file. So what we do in this method is we have a password file where username and their password are written in the plain text and that is provided to the server. So if you see this is an easy way to configure but it's the least secure. So the file can, someone can gain access to the file and modify that and do harmful operations to the Kubernetes clusters. If we talk about certificates, this is also a way but the problem with certificates is it requires a lot of manual configurations and also it does not work at the scale. So if you have a cluster where you are going to manage a lot of user, so it is not a good, I would say it is going to be complex to manage all those users with certificates. We also have a way of service account token. So this is simple to configure. So in this, you create a token, you associate that with a service account in Kubernetes and then you provide access to the service account and perform operations accordingly. But the problem with this is like those tokens are basically short lived. So they expire after 24 hours. So you need a way to refresh those tokens every time. So that is the challenge with service account tokens. OK, OIDC we are going to cover. Introduction to OIDC, it stands for OpenID Connect and it is an identity layer on top of OOR 2.0 protocol. OOR 2.0, if I talk a bit about it, it mostly deals with allowing application access data of other application on behalf of a user but in OIDC along with the access information, other information are also shared. Then it is most commonly used in SSO scenarios and some of the popular identity provider that supports OIDC are Google, Microsoft Active Azure Directory, OAuth and Okta. OK, before we jump into Kubernetes with OIDC, I will tell you about some of the terminologies that we are going to talk in next few slides. So first one is identity provider. So these are the services that authenticates user and provide user information. Clients are the one that requests user information from the identity provider and it can be anything like mobile application, web application and services as well. Then tokens, so I have been talking about user information. So they are shared in the form of tokens. So we have access token, ID token and refresh token. So ID and access token are for the information but the refresh token is used to renew the ID and access token if they expire. Scopes, so scopes determine what level of permission that client is asking from the identity provider. So we are talking about user information. So let's say the client can ask for email or maybe profile of the user. So that goes into the scopes. Then flows, so flow define how the client is going to get the token from the identity provider. So we have different flow based on what type of client you have like mobile application or web application. I'm going to talk about authorization code flow. This is common and popular. Okay. This is, I hope this is visible. So this is authorization code flow and this is how the interaction between client and the identity provider happens. So way before this interaction happens, so you need to, as a client, you need to register yourself into the identity provider and you will get with the client ID and client secret that you can use later to interact with the identity provider. So once that registration process is done, so let's say a user requested for a resource. So what client does is it sends a request to the identity provider at the authorized endpoint and then the request goes to the authorized endpoint and then the authorization server pops up a screen where the user is asked to authenticate themselves and so once let's say a user is authenticated, the authorization sends back authorization code to the client and then client uses that authorization code and it uses the client ID secret and the authorization code that is given and sends the request back to the authorization server at the token endpoint to get all the tokens. So then it gets ID token, access token and refresh token as well. Give me a second. Okay. So let's say once the token is obtained by the client, then it extracts the token, validates it and then gets the information and then uses the access token to access the resources. So this is the main workflow and these are the two main endpoints that are used in it, so authorized and the token. Okay. So Kubernetes OIDC workflow. So this workflow is from the Kubernetes official docs and if you see this is almost similar to what we discussed in the previous slide but the only difference is how you are getting the token. So if you see, so in Kubernetes we use kubectl. So kubectl being a console application, it does not provide us with a web browser. So I mean you either need to get the token manually or use some kubectl plugins to get the token for you and then once you, so if you see, once you log into identity provider and you get the access token, ID token and refresh token, you call the kubectl and provide the token as a token flag and once API server gets the token, it validates the token and then it extracts the user information and see if that user is authorized to perform the operation that is requested and then returns the result back to the kubectl. So this is how this flow looks like. We will see the authorization part later in some slide. Configuring Kubernetes with OIDC. So after this flow, let's say if someone wants to configure their Kubernetes clusters with OIDC. So there are three main steps and this is mostly common with all the identity providers. First one is configure your OIDC provider. So you need to register your client into the identity provider and get the client ID and secret. Then second step would be to update your Kubernetes API server configuration. I mean, there are flags that are available like OIDC issuer, URL, client ID, and username claim. So you need to update those and then at the end, you need to configure your kubectl so that those tokens could be provided to the kubectl. So either you can use the token flag or the kts authenticator. So this authenticator sets your kubectl file accordingly so that you get the token for your use. OK, so authorization part. So if I go back a few slides, I was talking about this user authorized part. So let's say you get the token. Now, a kubectl server has validated the token. That means the user is authenticated. Now comes the authorization part, like what all operations the user can perform. So first of all, there is a field in the token that is pre-configured for mapping. So let's say you have some of the information in the token like email username. So one of the flags, one of the key is already configured to be used as a mapping. So what API server does is map the user information, user key that we get from the token to one of the user accounts. And then it applies RBAC. And then let's say a user request for a resource. Then it checks for the user account and the RBAC access that the account has. And then it gets back the result. So this is how the authorization takes place. So you have the ID token. You get a key from them. And then you map it to a user account. And then you apply RBAC. And then kubepi server will automatically evaluate the RBAC. OK. So kubepi server automatically evaluates the RBAC and then sends back the result. So benefits of using OIDC. So these are some of the benefits So centralized user management. So with OIDC in place, you don't have to manage users inside the Kubernetes clusters. You can delegate those requests to the identity provider. It also helps with, let's say, you have a multiple cluster. You don't have to manage users for all of them. You can just set them at one place and then use them in multiple clusters. Second is improve security. So OIDC uses a token-based approach. So you have your token that comes with the expiration. And you can also revoke the access. That is with the improved security. If we talk about simplified authentication, so as a user, I do not have to remember username and password for each of the clusters. I can just have one username password and then I can log into multiple cluster and perform operations. And hence, access control capabilities. So in identity provider, you can also, I would say, you can also set up roles and provide groups to the user. So while getting the information, instead of ID, you can get the group information and then map that to the Kubernetes clusters. So that also works. Best practices for OIDC implementation. So these are some of the best practices. There are many more. I have listed a few. So enable RBEC. So even though a user is authenticated, let's say you should always try to enable RBEC because even though it is authenticated, if they do not have RBEC set, they won't be able to perform any operations. Then regularly update your identity provider. Then implement MFA. And the important one is securely store and rotate client secret. So I was talking about this in two, three previous slides. We get the client secret. So we should rotate it accordingly and securely store it because that is the one that is important for identity provider to authenticate the clients using client ID and secret. And then regularly review and test the configurations. So these are some of the best practices. OK, I think this is a lightning talk. So we can't take question, but you can connect to me offline and then we can get your answers. Thank you. That's all I had. Thanks, Akansha.