[FEAT] Should not require tailscale auth key if tailscale is already up

[joshproehl]

Is your feature request related to a problem? Please describe.
After running my playbook for the first time using the suggested TAILSCALE_KEY env variable method, and passing it a single-use pre-authorized tailscale key, the server I was running the playbook on is successfully on my tailscale network.

Unfortunately when I attempt to re-run my playbook, it halts at the "Tailscale Auth Key Required" step.

Describe the solution you'd like
I would like any servers where the playbook has already been run and tailscale is already on my tailnet, to not fail and request an auth key.

Describe alternatives you've considered
I could store a permanent auth key in my vault and have that provided as an auth key each time, but I would prefer not to.

I also attempted to pass default='fake_key' to the lookup() function, but got the same Tailscale Auth Key Required error

Additional context
Given the documentation provided, I assumed that I would either be running my auth key against a single server (--limit server.fqdn) while using a single-use pre-approved key, or running it against a collection of servers with a reusable key. I did not expect that I would need to keep an available auth_key on my tailnet.

[artis3n]

Hmm that is a good point. I think this will need to be a breaking change, turning the authkey parameter into an optional parameter.

[joshproehl]

For what it's worth, I'm perfectly willing to admit that I'm using it wrong. This could easily be an issue of "better document the expected method of managing tailscale_authkey" as well.

Based on the fact that this would be a breaking change, I doubly feel like I must be doing it wrong. I'm basing this ER on the idea that an auth key should be used only once, or at least used for a very short time, which seems to be what Tailscale encourages, but I'm happy to be wrong about that.

If it's true that keys should be consumed when adding nodes, I might go so far as to build getting the key from the env directly into the playbook, to discourage users from even attempting to create a long-lived auth key and storing it in their vault or anything like that. (and change the documentation to encourage either creating a multi-use key if adding multiple nodes, or a single-use key if limiting to just one node.) Auth

Having thought about it a bit however, my original idea of just skipping if the auth key requirement task if tailscale status returns up has some edge cases:

1. What if you're trying to re-auth the node to a different tailnet?
2. What if the node didn't have key expiry disabled and needs to re-auth?

Finally, and I'm not suggesting this, but simply thinking in public: I wonder if the better way to handle this wouldn't actually be to handle creating the device specific auth keys transparently, using the API, and an API key or oauth login. Setting the args as flags in group_vars or host_vars, dropping the api key into your vault, and then simply calling the role with the API key. (I've been working with the zabbix_agent role recently, that inspired the thought.)
The problem I foresee here is that the Tailscale API key lasts only 90 days at most, necessitating rotating the API key in your vault file. Irritating, but I suppose even if you used long-lived auth keys they also expire after 90 days so we're sort of back where we started.
OAuth comes with another set of headaches and complicates tagging requirements for the tailnet as well.

Sorry for shotgunning so much information at you. Hopefully I'm simply using it wrong. 😄