Use Open ID Connect for Kubernetes API server

welcome to a brand new video on kubernetes authentication and more specifically on using Open ID Connect tokens to authenticate against our kubernetes cluster we're finally at a point where we can point our API server in the communities cluster or more specifically in the mini cube cluster that we have up and running to use the identity provider and token issuer that we've spun up in the previous episode if you don't know how open ID Connect works don't worry just watch the open ID Connect video first and if you don't have your identity provider and token issuer up and running yet just watch the video on spinning up key cloak we've used key cloak for this purpose in the past video let's move to the terminal and get started in the previous video we've got created a key cloak instance and we're using that with a docker setup here if you don't have that code ready yet and you don't want to go through the video you can just get cloned this repository and follow the instructions in the reading I've already done that so no need for me to do it right now all I want to do is a docker compose up minus D so it runs in detached mode in the background doesn't block my terminal here and this will now make sure the key cloak is running on your machine and then you can point your browser to localhost 8 443 and that's an HTTP yes and there's key cloak and then you can log into the administration console and the dummy passwords I'm already locked in but the dummy passwords would be admin and pass s configured in the docker compose file so our very first challenge here is for our mini Q cluster which runs in a virtual machine to discover this Kiko instance which runs on my host machine it is running in a docker container but it's currently exposed on to local host here and local host of course has a very different meaning inside of this virtual machine as it would have on on my machine so if we take a look at this token issuer URL and go to our browser as our to our console I can they curl this here because I'm on my machine but if I go mini Cuba I've already started mini Cuba in the background it's just it doesn't have any sort of specific configuration just to have a VM with mini cube running if I do a mini cube SSH in here and try to do the exact same thing curl to here then what I need to specify the minus K option because I'm not specifying the certificate authority then I am getting some sort of completely different response and this is actually coming from the kubernetes api because inside of this mini cube machine on port 80 443 there is the the cuban atapi the api server running and not our key clogged instance at all which is running outside of the vm on my host machine luckily this is quite easy to fix though because i'm spinning a mini cube or i'm using mini cube with the default configuration which means it uses VirtualBox for its virtualization in the background and on VirtualBox there's a magic IP in this network that points to the host machine so if we simply replace the local host here with 10.0 - - and then go to port 8 443 and ah films master then we get the same response that we got before so this is not mac OS specific this should be the same on linux or in Windows but it is VirtualBox specific so if you're not using VirtualBox but another virtualization for mini cube then you might have to change this IP and this matching IP is also not very well documented anywhere there's a github issue where um someone basically just says yeah this works and here's the magic IP you can use that and that's actually where I got it from some time ago as well so yeah can't really tell you where exactly it's coming from err if you can configure this somewhere within VirtualBox but I know that it works and I've seen it working in local CI setups where people use mini cube in their in their local tests and on CI and yeah this works consistently across machines so next up before we configure our mini cube API server to use this token issuer what we haven't done yet so far is inspect one of those tokens to see what they look like and even retrieve a token and the easiest way to do that is just to use the password grand Fleur flow and for that let's just go back to our discovery um page and take the token endpoint here and with that we can do a curl - Kay because they're not specific specifications to that URL and that'll give us some error saying invalid requests missing parameter grant type but we can add that and it's more than just the grant type is missing this has to be specified with the minus D option so it's a form encoded body and the first one is the grande type as I said password is the easiest for our example here it does come with a very big disadvantage which is basically we have to send the user credentials with this request so it might not be the safest way for production but perfectly fine for our example here next up is the client ID in the previous video we've created a client called kuberan a DS cluster if you haven't watched the previous video and just run the docker compose command please log into the key cloak UI and create this client it doesn't need any specific configuration it just needs to be called whatever you specify here and then we have to specify the username and I'm using the admin user here which is of course also very far from a production use case the key klog admin would not be used to retrieve a token to login to the Kuban 80's cluster but for a simple testing example that's perfectly fine and the password was passed so let's run that and what we see here is we get don't see anything really because it's quite hard to see but JQ makes it a bit easier we get a access token and we get a refresh token here however an access token is not what we want if we go back to here and look at the docs it tells you somewhere up here to identify the user the Authenticator uses the ID token not the access token so that's not quite what we want however we can we can get that if we turn the scope to open ID and then specify the respond response type equals to ID underscore token and again pipe that into JQ just to make it a bit easier to see then we have an ID token here as well now so let's modify our JQ option here a bit let's only get the ID token and the minus R option so it removes the quotes around it so there's the token and now I can pipe it into PV copy a PV copy is Mac OS specific just to copy it into the clipboard this might be a different command on your operating system or you can just use T MUX or the mouse or whatever way you want to copy this and I want to copy this because now I can paste it into JWT io and in here already how to token from before let's remove that first and paste that here and now we can take a look at this token okay so why did I want to inspect this token two reasons basically one is just to show how it works what Q&A T's will do with this token and the other is to highlight an upcoming problem that will be quite easy to fix but at first how what does kubernetes do with that remember this is an ID token not an access token so this is not about authorization all authorization will happen within the cluster using our back or could potentially use groups in the token as well but this token is about identifying the user so this is to prove that whoever claims they are is actually who they are and that is usually done with the subject fields so there's a subject field in this case here is a UUID that points to this specific user it is just our admin user and this admin user also doesn't have an email configured otherwise we might get the field email and email is very valid because emails are globally unique so emails are a very valid way for identifying the person based on their token as well in this case since we don't have the email we'll probably go with the subject here but that's as easy as changing a parameter in the configuration however there is another issue coming up we just told our mini acute cluster or didn't tell it yet but we just found out that we will have to tell it the API server in there to use this magic IP from VirtualBox which is 10 0 to 2 however the token now says ok I was issued by a local host 8 4 4 3 so the first thing the API server will say is I don't care about this token this wasn't issued by a token issuer that I'm configured to trust because I only trust 10.0 2 2 but this was issued by local host so if we want to successfully issue a token on our local machine that will be accepted by our key Bernese cluster there is one additional step that we have to do and that is create an IP alias that points to local host that is called 10.0 2 because if we use that to access or key cloak it will issue a token based on that URL as a token issue and on Mac this is quite easy on Linux also on Windows to be honest I have no idea but on Mac what you can do is sudo ifconfig and then LS 0 that's the loopback interface and just add 10.0 sorry up 2.2 and at the word alias I need to enter my password and now I have an alias for that you are all configured so if I go back to our previous request and modify localhost in here and replace it with 10.0 done 2.2 and run that well remove the PP copy otherwise we won't see any output then you can see it still works and if I do add the PP copy again and go back to here and paste that in here again then you can see that this token was issued for this or issued by this token issuer and this is the one that will also tell our community's API to trust in production of course you would have a cname here or some fully qualified domain name that is globally reachable and that you have dns configured somewhere so you wouldn't ever run into this problem but I'm a big fan of having everything that you do run also able to run locally because it's much easier for figuring out how stuff works and also quite good to to understand what goes on in the background this does of course also mean that the SSL certificate that we've created also needs to be allowed for this specific IP if we issue it for for localhost then the next issue that we would run into is the certificate not being valid for localhost but if you just cloned my repository I've already made sure to add the magic IP there so if you have a different magic IP you would have to to create a different certificate but if I just scroll down here might be a bit small to see no because unfortunately the zoom doesn't zoom this in but it does have a well this is of course the certificate for JWT io and that won't tell me anything but if I go back to key cloak here and if I take a look at that certificate and scroll down here a bit we can see then we have a subject alternative name with an IP address of this IP address so as long as we trust the certificate authority that signed that certificate it will be a valid certificate okay so now all we have to do is start up mini cube and configure it to use the open ID issuer that we have here and I think I already have a mini cube running so I won't just delete that and now we can do a mini cube start and add our famous extra config option and again it's the API server we're talking about because we want authentication and then in there we have au ID C dot issuer URL and that we can grab from here so let's go to the next tab here but again this has localhost in here so let's put that to our magic URL and yes I haven't trusted this yet also haven't added the certificate authority also doesn't keep my zoom settings apparently so we can add this issuer URL here and as we've explained in the video on open ID connect because it has that URL it can retrieve this page the roles of viewing in our browser right here and this contains all the configuration that you ever need so it's very easy to configure all you have to do is paste this single URL here then we have to add some other configuration authentication might be easier just copy that not bad but that and instead of the assure you are all we now want to point the username claim and that is that we said before this is what will identify the user and it's easiest to just use the subject here and then let's copy that line again and replace the username claim with the client ID so here Q Bernays will check whether this token was actually issued for our client or maybe not for someone else and this we have pointed to kuberan a DS - cluster so let's start up mini cube and I'll be back once it's running coal looks like it's up and running unfortunately the last attempt didn't quite work yet and that is because for once I misspelled something and the others I also forgot something so if we go back here one thing issuer URL there's this NGO specific syntax of writing acronyms well-known acronyms in the same capitalization as the beginning of the word so because the U is here camel case that means the rest of the word also needs to be camel cased so we need that and also of course we were talking about self-signed certificates all the time yet I have not specified the CA file here so even with the issue above fixed we would probably run into this issue next so the CA file is if you're using my github repository to spin a key cloak with docker compose file and it's just the current working directory if you're in it slash root CA dot CRT if you have used a different root certificate to self sign your certificate you need to specify there if you're not using a self-signed certificate but one by a trusted Authority then you can completely omit that last line okay so let's start it up again and let's see what happens this time cool also started up much faster at this time so let's give it a shot so far we've always been curling the API just to retrieve a list of namespaces to see whether in the authentication worked so let's do the exact same thing again let's go to HTTP mini q IP eight four four three four the communities API to listen on and API everyone namespaces notice I'm not specifying any token right now so we're expecting a 401 unauthorized even though technically it's more of an unauthenticated okay so now that we have that let's go back in our history and get this thing here for retrieving or token instead of typing it into PB copy I'll just save it into a file that I will call token and now if we go back here we can specify another header some minus h4 authorization again it's technically authentication but the standard calls the header authorization and there we can have bearer because it's a the tokens of typing bear it's a bearer token and then we can just copy the contents of our token file here and let's see what happens we get a response from the cue burn a DS API so we've just successfully authenticated using a open ID connect token and just to prove that this token is actually being evaluated here we can no modify this token and since the last part of the token is the signature by simply changing one character of the signature the entire token should be invalid not so let's try it and let's go back here with our file and we get 401 unauthorized because this token has now been messed with so this concludes our basically three part series we on open ID connect within this series on authorization oh so sorry on authentication methods for cuber Nettie's that we've all shown to make work with our mini cube cluster now a couple of things that we ran into here like the self signed certificate or a need for the self signed certificate and also this magic IP here are very specific to a local set up you will not run into them when you run this in production when you have a trusted certificate authority and all sorry a trusted open ID identity provider and token issuer that you have a proper certificate for signed by a known Authority then you can just omit all of this stuff where you point to a specific certificate authority that was used because if you use a trusted one it'll automatically be trusted but basically all of the configuration and all of the flows of how it works will be the same so I hope you could get quite some interesting learnings out of this small exercise if you liked it feel free to subscribe leave a thumbs up or a comment with feedback on how we can make the next series better and also of course with wishes for other topics to touch up

Channel: kubucation

Views: 19,060

Keywords: OpenID Connect, Kubernetes, API, Authentication, Token, Web Token, JSON Web Token, JWT, Keycloak, Identity Provider, Cluster, Cloud, Cloud Native, Acess Control, Access Management

Id: gJ81eaGlN_I

Length: 18min 55sec (1135 seconds)

Published: Sat Mar 31 2018