Hey everyone, welcome back to KubeAcademy. My name is John Harris and I'm a senior cloud native architect at VMware. In today's episode we're going to talk about authentication.

When we talk about authentication what we really mean is, "How do I establish my identity and prove my identity to Kumernetes?" So we're not talking here about what I can do in the cluster, that's authorization and covered by RBAC, so you should check out my colleague Timmy Carr's videos on that. Here we're just about establishing our identity. I'm going to talk about three of the ways. There are probably about seven or eight in total, but the main three ways that you might come across as a user.

The first one we're going to look at is certificate authentication. This is probably the most common. The first one you'll come up against. So certificate of authentication basically just means in the cluster we run a client certificate authority. A certificate authority that has to sign all the client certificates to prove when a user is trying to connect to the Kumernetes API server.

If we look at the API server static manifest, so this is my API server, how it's running. I have this flag in here client-ca file/etc/kubernetes/pki.ca.crt, that's my Kumernetes CA. So all client certificates who want to try and connect to the server need to be signed by this.

What I have done is create a certificate signing request for the username of John, in a group system masters, and I've submitted to the cluster already. I've logged in as an admin, approved it, and it's given me a certificate back. I can take a look at that certificate here, so it's been signed by that CA because I submitted it through the cluster. I can see the issuer is Kumernetes and the subject, the common name is John, so that's the user that I will be authenticated as with Kumernetes. Anything in the organizations will be the group, so I'm authenticating in the system masters.

So what that looks like in the kubeconfig is we can see that is the client certificate data. So the certificate we just saw, that's basics D4 encoded and that's here. So kubectl is going to use that certificate, present it to Kumernetes when I try and do anything. If I export my kubeconfig to be this kubeconfig, and then I can do a get nodes, and we can see ... And I've given permission for the John user to have admin in this cluster, so now I can do everything in this cluster with using this kubeconfig.

The second mode that I want to talk about is AWS IAM Authenticator, or really the exec method of kubes' config. So if you're working with AWS what you can do is you can use IAM roles to authenticate with your Kumernetes cluster. There's a number of different pieces that make this work but the main one is the AWS IAM Authenticator tool, which is a CLI that runs where you're running kubectl. It's also a service component that runs in the cluster. It runs as a authentication webhook.

First of all let's take a look at the API server, see what flags we need to add for that. It's really just one. We need to tell it to use this authentication token webhook. In this file is details about where to find the server. The server is running as a DaemonSet. In the kube-system name space we can see this AWS IAM Authenticator.

So what's the flow for this? What happens is when I run kubectl it's going to use my kubeconfig. The kubeconfig says, "Run the AWS IAM Authenticator tool on my machine and use this role that I, as a user, have access to assume." Right? So I have private credentials, AWS credentials, on this machine. It's going to use that profile. It's going to generate a pre-signed URL to the AWS token API. Then it's going to send that through to the API server. The API server is going to send that on to that authentication webhook, which is my server side component running in the cluster. It's going to use that pre-signed URL to talk to the get-caller-identity API in IAM. That's going to come back and prove my identity, that I am that AWS user.

The final piece is I need to map that AWS role or AWS user to the user that I can assume in the Kumernetes cluster. I do that with the use of this config map. So we could see AWS IAM Authenticator. I can see here that I'm mapping the role, this Kumernetes admin which is just a role that I created in IAM. It doesn't have to have any AWS permissions. It's just a dummy role that I can assume. It maps to the Kumernetes admin user in the Kumernetes cluster. Again, I could list out the groups.

So if I export kubeconfig to equal my AWS auth and now I do get nodes again. This time, again, I'm still admin because I'm the Kumernetes admin and I've exported my AWS creds into this session. If I take a look at what the kubeconfig actually looks like for this, instead of a certificate this time in the user section it's execing this AWS IAM Authenticator tool and it's passing in the role that I want to assume or authenticate. It's going to use my AWS credentials, my secret AWS credentials, to generate a pre-signed URL that that server side component, the authentication webhook, is going to send to Amazon to prove my identity. Then it can map that back to Kumernetes using that config map.

Then the last one that I want to talk about is OIDC, this is OpenID Connect. It's a standard built on top of OAuth2 specifically for authentication. So this flow is if you want to federate your ... Or delegate your access out to another system. Let's say I wanted to be able to use my GitHub ID, or my Google ID, or my Microsoft ID, something like that, to log into my Kumernetes cluster.

Again, we're going to take a look at the API server, how we set this up. What I need to do is tell the API server where the OIDC issuer is. I'll talk about what Dex is in a second. What the client ID is, what the username claims, so to look in the information that's returned by my identity provider and which piece of information in there should I use as the name that I want to authenticate as in Kumernetes. Do I want to use the email address, like my Gmail email address that comes back or do I want to use my full name that comes back from that call?

So I need to set up my API server. What my API server is going to do it's going to call out to this issuer URL, Dex. Dex is an IdP, an Identity Provider because Kumernetes, as you can see, only really supports one of these flags. But what happens if I want to let my users login through a number of different methods, right? Ones which will give them the choice between Google, or GitHub, or Facebook, or something like that. What Dex does is it federates those other identity providers behind it, so then I can just talk to Dex.

What Dex is going to do is do the backend piece of that. It's going to log me into those other systems and I'll show you that in the browser. Then it's going to sign a token using its key, so this URL is basically just so the Kumernetes API server can talk to Dex, discover its keys. So that when I then submit a request to the API server later on, using those tokens, the Kumernetes API server can make sure, using those public keys, that that is a valid request.

What I'm going to do is I'm going to flip over to my browser. I'm going to ... I'm using a project called Gangway, which is like a front-end for Dex. It allows us to take those tokens and just generate kubeconfigs out of them because that's what I need to contact the cluster. So if I hit sign in this is going to take me to Dex. I have two different LDAP backends at the back of Dex. This could be GitHub, this could be Facebook, Microsoft, Google, whatever. I'm going to login here with some predefined details, hit login. What that's going to do is log into my backend LDAP. Then it's going to come back and return a signed token. Then Gangway's going to allow me to easily generate a kubeconfig from that, so I can download this kubeconfig.

What I can do is I already have this kubeconfig downloaded. If I cat kubeconfig, here we go. In this case, again, the user section looks different again. This time the auth provider is inside here, it's like OADC. I've got the issuer URL in here and I've got this ID token that was returned, this is the signed token from Dex. So Dex has talked to LDAP, it's verified who I am because I had to login. Its signed that token for me and it sent it back. This time, when I log into Kumernetes, Kumernetes is going to use the key that it discovered from that public Dex endpoint to make sure this is a valid token. That will prove my identity as this case the username that comes up at the top here in the name. Then I can use that username in my all back to control what that user can do in the cluster.

This is just scratching the surface of authentication. Obviously it's a pretty complex topic, we didn't go very deeply, but I hope this has been useful just to kind of understand the three main ways that you might come across authenticating to your Kumernetes cluster as a user. Let us know your feedback and we'll put a lot more details about all of these methods, and some of the others, down below in the ... Where are we? Down here. So let us know, hope you enjoyed, and we'll catch you in the next episode. Thanks.