that this issue was identified as a pain point. My use case:
I too want ephemeral nodes simultaneously with keeping Device Authorization for laptops
and am wondering if this is “on the roadmap”. Having the Tailscale API allow programmatic device authorization is a step in the right direction, but am wondering what an “ideal short-term solution” could be to hook up the Tailscale API Device Authorization with provisioning ephemeral nodes.
First, it seems like that the Tailscale API is not scoped by roles, that is to say, if you have a Tailscale API key then it allows you to do everything on the API, and is not restricted to just the APIs you might need. Is this a correct understanding of the Tailscale API as it is today?
If this is the case, then the ephemeral nodes cannot call the Tailscale API to self-authorize, as that would involve letting loose an API key that grants too much power for error and mis-use. Therefore, the only solution I see (currently) are two level of hackery.
Run a scheduled job on a completely different (locked-down) server that constantly queries the API for new un-authorized devices with some bit of metadata (each ephemeral node could be tagged with a special tag like tag:ephemeral) and authorizes them
have the ephemeral node call out to this locked-down server (machine would have to be on a public IP as we don’t yet have access to our tailnet) to ask it to authorize it. Again, the device would have the tag:ephemeral to indicate that it was worthy of being authorized when it calls out to the locked-down server
I am just spit-balling possible solutions, and am hoping to hear if these are solutions in the wild that tackle this. Hopefully, I’m missing something fundamental.
I have a similar problem. I am launching proxy nodes in AWS that need to be automatically authenticated. Currently, I’m generating an “Auth Key” manually in the Tailscale GUI and providing it to the EC2 instance. However, there are two problems with this; first, the auth keys expire after 90 days, so I have to continually update this key. Second, the auth keys appear to be linked to my user, so if I go away (get fired, change jobs, etc.) then all of my proxy nodes will fail to refresh.
I guess my question is what is the best way to authenticate server nodes (ie. proxies)? I’m thinking that a long lived “account” auth key would work, but I’m open to any ideas.
I guess my question is what is the best way to authenticate server nodes (ie. proxies)? I’m thinking that a long lived “account” auth key would work, but I’m open to any ideas.
Tags are the usual way to handle this. When a node is tagged it ceases to be owned by the User who created it. Tags can be assigned in the authkey which creates the node.
Hmmm… I am using tags and the “auto-approve” ACL property to automatically approve the advertised routes. However, it’s my understanding that you need to either manually authenticate the node (ie visit a webpage) or use the ---auth-key parameter to the tailscale up command.
Are you suggesting that I can use the --advertise-tags=<tags> parameter to automatically authenticate a node? If so, that would be great, but it seems like it might be a security hole. What would prevent anyone from guessing my tag name and using that to authenticate some random node on my network?
No, --advertise-tags alone can not add a node to your tailnet. You must either use tailscale up --advertise-tags=... and log in via the URL it prints, or you create an authkey with tags already applied to it and use tailscale up --authkey=...
The point is that once a device has been authenticated, using either browser or authkey, and tags are applied then the device ceases to actually be owned by the user. The device is now controlled by the Tag. Deletion of the User has no impact on tagged nodes, even those nodes which were originally created by that user.
Ah, yeah, that’s how I figured it works. My problem with short lived auth keys is that I’m running proxy nodes in AWS and want to be able to replace them at will (nightly, monthly, etc.) The process works, until the auth key expires and we have to issue a new one. I was hoping that there was some sort of long-lived auth key that I could use to continually build / replace nodes with.