Tailscale OAuth

[Techman]

After having to recently rotate my ephemeral auth key, I spent some time after thinking about possible solutions to this problem. Although it would be great from an automation perspective, I doubt Tailscale is changing their position on key expiry anytime soon.

This brings me to the OAuth client documentation, where there is a section regarding key generation.

I can think of one straightforward way of implementing this, but there is room to consider variations of this approach. Here is how I envision this working:

1. Store OAuth client ID and secret in a configuration file, along with ACL tag(s).
2. When generating a new initramfs, have a hook that calls a script to generate a new ephemeral key.
3. Embed this key in the initramfs.

Here are some questions about this approach that I thought of:

1. What if someone force updates their initramfs without rebooting, resulting in many keys being generated?
   • Keys have a maximum life of 90 days, so they would not persist too long.
   • Could have a check to see if a generated key already exists and has a long enough (>= 30 days) duration.
2. What about systems that do not reboot often?
   • Could have a [systemd] timer to generate an auth key and update the initramfs if there has not been a recent (< 30 days) change.

[darkrain42]

I think this is an interesting idea, but I don't think it's something I would entertain fixing in this project itself.

This functionality ideally wouldn't be triggered during initramfs construction, but if it were, I think it would need to be intelligent enough to know whether an existing auth key with a sufficient lifetime is already present. (It's pretty common for me to see apt installs/upgrades rebuild the initrds multiple times in a single run).

I think the best way to do this is a completely separate periodic task (cron, systemd, etc) that generates or fetches a token, updates the config file, and then triggers update-initramfs itself.

[Techman]

I think this is an interesting idea, but I don't think it's something I would entertain fixing in this project itself.

Why not? Ultimately, Tailscale's design limitation means that a person has to manually keep track of key expiry, and a lapse in that focus can leave remote machines in a potentially annoying situation to recover. It looks like an OAuth client is their intended way to solve this problem.

I am not opposed to the timer approach of generating a key separately. Given their relatively short expiry times, though, it may be less complex to simply have an API call to get a new key every time the initramfs is built.

I would like to keep this issue open, if possible. If there is no desire at all to work on this, perhaps I can look into this when I have time, but I have little experience writing sophisticated shell scripts. This project is pretty much the only solution so far for embedding Tailscale in the initramfs, at least for Debian-like systems.

[darkrain42]

First, I haven't tested this, but reading https://tailscale.com/kb/1215/oauth-clients#register-new-nodes-using-oauth-credentials makes me think that the simplest way to support using OAuth creds is doing it the way described in that section -- use the oauth token directly as the key, and then also pass --advertise-tags=....

(Personally, I would want that to work with the file: syntax so the oauth token is stored in a separate file in /etc/tailscale/initramfs/)

(If that does work, then I absolutely do want to update the docs)

---

Why not? Ultimately, Tailscale's design limitation means that a person has to manually keep track of key expiry

Extra complexity, and then the risk of potential scope creep for "well, but I have this slightly different way I want to use the API and the implementation as coded doesn't support that". Every new option, even if seemingly straightforward, is a non-zero maintenance burden.

And the automation to address this doesn't actually need to exist in this project, since I don't see any need for tight integration or (necessarily) any modifications to either the initramfs-tools hook (the script that runs when an initramfs is generating) or the init-premount / init-bottom scripts (the scripts that run in the initramfs).

---

I'll reopen this, because the API actually looked simpler to deal with than I was thinking.

In addition to my suggestion at the top of this comment, I also came across https://github.com/tailscale-dev/examples-api-scripts/blob/main/make-auth-key/makeauthkey.sh, which is a fairly comprehensive example.

[darkrain42]

First, I haven't tested this, but reading https://tailscale.com/kb/1215/oauth-clients#register-new-nodes-using-oauth-credentials makes me think that the simplest way to support using OAuth creds is doing it the way described in that section -- use the oauth token directly as the key, and then also pass --advertise-tags=....

Yeah, this works. The downside to this is that the oauth token goes into the unencrypted initrd, and anyone with that token can register both ephemeral and non-ephemeral nodes. (And, probably, generate further auth tokens)

In other words, I think I've convinced myself there's still value in having a cron script/systemd timer running on the host that interacts with the tailscale API and generates a key, and it's that key that goes in the initrd.