Proxmox users, you're probably familiar at this point with this screen. Logging in, it kind of is a bit of a pain, right? And wouldn't it be nice if you could reuse the identity of your tail scale network, your tailnet, to automatically log into Proxmox for you?
Well, in today's video, that's exactly what I'm gonna show you. I'm gonna show you how to configure something called TSIDP. It's an experimental identity provider that tail scale ship.
And I'm gonna show you how to plug that into Proxmox so that you can automatically log into Proxmox just by virtue of being connected to a specific tail net. So I have here my demo Proxmox cluster. It's just running on three Dell, you know, those small form factor PCs in my little rack next door.
You can see I've got three nodes in this cluster and Hammond seems to crash a lot. Hmm, can't think why, Top Gear joke. Anyway, so what I wanted to show you is how to configure Proxmox with something called tail scale IDP, TSIDP.
Full disclaimer, this is an experimental piece of software and shouldn't be relied on in production, blah, blah, blah, here be dragons, all right? It works though, and certainly in a home lab setting, it should be stable enough. So what we're gonna do is use the Proxmox realms feature to add a new open ID connect server.
So up here in your data center, you'll notice that there's a whole bunch of stuff, certainly before I prepped this video, stuff I'd never clicked on, but down here, there's a section called realms and you can actually add an open ID connect server. And of course that's what TSIDP is gonna implement for us. So what we need to do first is build the binary that's going to run TSIDP.
It's a statically compiled Go app, so it only takes a second. So the first thing we're gonna need to do is actually compile the TSIDP binary. We can do that by going to GitHub and the tailscale/tailscale git repository.
Up here in the top right, there is a big green code button. And if you copy that URL to your clipboard and then just go to any directory on your local system, it doesn't really matter what it is, I'm just gonna go into git here and then just go into the tailscale directory, makes sense, right? And then do git clone.
I like to organize all of my git repos just this way. It's up to you, wherever you put this, doesn't really matter. Once that's cloned, go ahead and change into the tailscale directory and your structure should look something like this.
The next command we're gonna want to enter is this one. It's called goos=linux. So I'm presupposing that the architecture that you're compiling this binary for is an AMD64x86 type chip.
And you can see the architecture we're compiling for here is AMD64. The nice thing about Go is that we can actually build binaries with different architectures from what we're actually compiling on. So this is running on an Apple Silicon MacBook, but I'm compiling for a Linux x86 target system.
So that's pretty nice. Once that command is done, we should have a new binary just in the root of the git repo here. And you can see tsidp is indeed now present.
So we're gonna want to SSH as, well, it's up to you. It could be root, it could be a user, but we're gonna need a way to get this binary onto the Proxmox host in question. So for me, you can see I've got SSH access here.
So I'm just gonna use scp to just copy that binary across. tsidp, so if I do scp, tsidp, and then root at, and then the IP address of the remote Proxmox host, this is gonna put that binary in the home directory of the root user on the remote Proxmox node. I'm then going to SSH back to the Proxmox node.
So 10 dot, in my case, 10. 42, 37. 10 is the remote Proxmox node.
And then we need to set some things up. We need to set a systemd service, an environments file, couple of other things. So lucky for you, here's one I made earlier, and there'll be a link to the code to do this down in the description, of course.
You can see this is just in a repo that I have up on GitHub here for video code snippets. There's a few other things from previous videos too, but this one, install tsidp dot shell is the script that we're gonna need to create. Let's take a very quick look at what it's doing before we go ahead and run it.
First things first, you need to run this script as root. Fine, we're doing some stuff here with varlib and etc, so that makes perfect sense. So we're going to use this directory here, varlib tsidp, to persist the state of the IDP service, 'cause essentially what tsidp does is it adds itself using the tsnet libraries to your tailnet as a node on your tailnet.
So then tsidp needs to store those keys in that state somewhere. So we're gonna put that in varlib tsidp, and I'm gonna set some permissions on that directory, nothing too crazy there. Then we need to set some environment variables, and you can see those down here.
We need to set the home directory, the ts host name, so I'm gonna call mine tsidp. This is the name that that node will get on your tailnet. Can be whatever you like, I just keep it simple with tsidp.
We then need to generate an auth key, so actually I should probably show you how to do that. Let's head over to our tailscale admin console at tailscale. com, get logged in.
Same as usual, just get logged in with your standard identity provider, then jump up to the top right where it says settings, and then personal settings in the bottom left where it says keys. Next I want to generate an auth key. I'm just gonna make it reusable.
I don't actually think I need to. I'm gonna leave all of the other settings alone, and then just copy this value to my clipboard and put it back into my little script over here. I'm gonna replace the value of ts_authkey with the auth key that we just generated.
And you see there's a couple of other things like state directory. We're gonna use varlib tsidp as we talked about. User space, this is where the tailscale is gonna use the user space version of it or not.
And then because, as I mentioned, this is a work in progress and not ready for production type code, we have to set a tailscale use work in progress code environment variable as well. Now to glue that all together, we're gonna use systemd to start the service and start the binary automatically when the system boots. And you can see here, this is just a pretty standard systemd unit file.
We're referencing the working directory here of where we're gonna put the binary, which is user local bin. Then exec start is again that binary there, and then the environment file where we configure things like our auth key and all that other stuff is referenced here. The only other thing is that we wait for the network to be online.
Obviously it's a network type service, so there's not much point in it being available before the network. Then the last thing is there's a couple of just helper commands down here for you to make sure you remember to copy your binary to the correct place and then do some system CTL commands. So with all that in mind, let's go ahead and just copy this onto our remote host.
It doesn't really matter what you call it. I'm just gonna call it install_itsidp. sh.
And this is written to run with bash. So I'm just gonna do bash install_itsidp. sh.
And that's it. All of the required stuff should be ready to go now. So the only other thing left to do of course, is copy that tsidp binary from this directory.
So we're in the slash root of the home directory of the root user. We wanna just copy that binary from here, tsidp to user local bin, and then we should be good to go. I think it's executable already, but it's always worth a quick check.
Yeah, you can see we've got the X here, which means executable. So we are good to go. Next thing to do is to do a system CTL daemon reload.
And then I want to actually just start the service. Now it will take after you start it, a minute, maybe less to actually add the node to your tail net, but we can monitor the status with a system CTL status, tsidp. And you can see there's a bunch of stuff happening in the backend here.
Now, if I go back to my tail scout admin console, we should see here that in any moment, I now have a brand new node called idp. Look at that. So I'm just gonna copy the fully qualified domain name here from my tail scout admin console.
Again, this is presupposing that you have a few things turned on in your tail net, magic DNS, as well as HTTPS certificates as well. So if you don't have those two things turned on, just click the enable button and you should be good to go. Then you can go to the URL itself and it will just show you a very basic webpage just to kind of prove it's actually working.
And then what you want to do is go to Proxmox and we can actually start configuring Proxmox to talk to tail scale. So what we want to do is go to the add button up here where it says, well, let me jump back a second. Even if you only have one host in your Proxmox cluster, you will still have this data center option at the top of the screen.
So click on data center, and then you're looking down under here where it says permissions. You want to go to realms and then add open ID connect server. In terms of what you need to put into these different boxes, first thing we want to put is just the HTTPS URL for the tail scale node that's on your tail net.
And then realm, we can just put, we can give this a name of tail scale if you want. You can call it whatever you like, it doesn't really matter. Client ID is unused as is client key actually.
We can set this to be the default. So every time we load up Proxmox from this point on, it's gonna ask us, do you want to log in using tail scale? And I'm gonna automatically create users as well.
The only other thing we have to change is the username claim must be email. And with that, we should be good to go. So I'm gonna click add over here and then I'm just gonna log out.
It's always a bit scary, but you'll notice that we now have a new option here. And if I want to log in, first of all, I have to make sure I'm actually on the tail net. You can see here I'm on the correct tail net.
And then I can just do log in with open ID connect. And that's it. I'm logged in using a tail and scales@gmail.
com using my tail scale identity. So any, just think about that for a second. If you have a small dev team and you're all using tail scale, you can now manage all the identities for your Proxmox cluster using tail scale.
Like I said, this is not a fully formed solution or fully production ready solution, but open ID connect is. And the whole idea behind this video is to show you that you can connect Proxmox to an open ID connect server and then reuse the identity that your tail net provides. So what you might notice is that this particular user doesn't really have any permissions to do anything.
So we're going to have to log out one more time, go to Linux standard authentication using PAM. And I think I typed in the wrong password, but what we want to do is just create a couple of groups and allow a couple of permissions so that we can actually do something useful with our new login or new authentication method. So first things first, we want to create a group here.
I'm just going to call this TS admins. You can call it whatever you like. And then in whatever reason, for whatever reason, it took me ages to find this.
If you actually click on the top here, I see one of these little arrows. I assume that this isn't an option. Turns out it is.
So what we can do is add a group permission here and I can give this particular group access to every single API endpoint. So I'm just going to do slash here and then TS admins role, no access. I'm going to give them administrator access and then click on add.
I'm then going to go down to users and then modify this tail and scales at Gmail user and just add them into the TS admins group right here. And now when I log out as root, I can then change again my realm to be tail scale and log in with open ID connect. And you'll see that I've got access now to all of my virtual machines and all the resources with inside the cluster.
Should also make sure to say that the Proxmox node itself must also be a node on the tail net so that it can resolve the TS. net DNS entry of where the IDP server is running. If you don't do that, you'll get the following error where it says open ID redirect failed, request 500 failed.
So you can see the node right now isn't currently running as a tail scale node. But if I do tail scale up, I'm already logged in. Again, I'll do status so you can see that.
I've got this small tail net here with a few nodes in it. And now if I try and log in, everything works just fine. So you just got to make sure that the node where the open ID connect stuff is configured.
In my case, it seems to be the first node in the Proxmox cluster. Make sure that's a node on your tail net and you should be fine. So that is a really quick, and I'm aware that was really fast, but just a quick fun little video for you to sort of look at TS IDP as providing identity within your tail net.
Obviously be aware there's from catch 22 situations. You've got to make sure the node that you're running the identity server on is always up or at least highly up within your cluster. There's no point having an identity server that's not available.
Otherwise the authentication can't take place. But that's just a scratching the surface really of what you can do using tail scale to reuse identity across nodes on your tail net. Thank you very much for watching.
And until next time, I've been Alex from tail scale.
