Enroll a tagged server safely

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

Define the tag owner first, generate a short-lived key with the tag:server tag, and store it in the deployment platform’s secret channel.

The order matters. tagOwners must permit the tag before a key can carry it. Generate the key in the admin console under Settings, Keys: one-off, short expiry (an hour is plenty for one deliberate enrollment), with tag:server pre-applied.

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.

Enroll without leaking

Pass it to tailscale up without committing or printing it:

sudo tailscale up --auth-key="$TS_AUTH_KEY" --advertise-tags=tag:server

The key arrives through an environment variable, so the literal value never lands in shell history. Resist running echo $TS_AUTH_KEY to “check it”. That is printing a password.

Verify, then clean up

Use a disposable key, verify the node is tagged rather than user-owned, clear the shell value, and revoke the key from the admin console.

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.

Revoke or delete the key when the enrollment is complete. 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.