Automation and device trust
Enroll a tagged server safely
Create a short-lived one-off key with a permitted tag, inject it without logging, and revoke it after enrollment.
Auth keys are credentials. Treat the value like a password, even when it can only be used once.
An unused one-off key in the wrong hands enrolls a device into your tailnet, carrying whatever tags it was created with. That device inherits every grant targeting those tags. The window may be small. The blast radius is not.
Prepare before generating
The order matters here. tagOwners must permit the tag before a key can carry it, so check the policy first. Your tag:server entry from the access module is enough.
Then generate the key in the admin console under Settings, Keys. Make it one-off, give it a short expiry, and pre-apply tag:server. An hour is plenty for one deliberate enrollment. If you have not used it within the hour, something went wrong anyway, and you want the key to die.
Store the value where secrets live in your platform: a secret manager, a CI secret, or an environment variable injected at deploy time. Not in a repo, not in a Dockerfile, not in a wiki page. All three happen more often than you would think.
Enroll without leaking
Pass the key to tailscale up through an environment variable, so the literal value never lands in your shell history:
sudo tailscale up --auth-key="$TS_AUTH_KEY" --advertise-tags=tag:server
Resist running echo $TS_AUTH_KEY to “check it”. That is printing a password to a terminal that may be recorded, logged, or screen-shared. If you need to confirm the variable is set, use test -n "$TS_AUTH_KEY" && echo set instead.
Verify, then clean up
Confirm the node is tagged rather than user-owned, then clear the shell value:
tailscale status
# 100.101.9.23 lab-server tagged-devices linux -
unset TS_AUTH_KEY
The owner column reading tagged-devices instead of your email is the confirmation that matters. This node’s identity is now its role. Policy rules that target tag:server apply to it, and rules that target your user do not.
Finally, revoke or delete the key in the admin console. Yes, even a spent one-off key. Removing it costs nothing and keeps the key list meaningful.
A tidy key list is the difference between noticing a rogue key and scrolling past it. When every key in the list has a name you recognize and a purpose you remember, the one that does not belong stands out immediately.
Lesson completed