Choose an authentication method

A person can open a browser and authenticate. An unattended server, container, or CI runner needs a non-interactive enrollment path.

Interactive login is the right default for anything with a human at the keyboard. The identity provider does the work, second factors apply, and the resulting node belongs to that person. The interesting decisions start when nobody is there to click.

The non-interactive options

A one-off auth key is the safest default for one server. It enrolls exactly one node, then becomes useless. Stolen after use, it is worth nothing.

sudo tailscale up --auth-key=tskey-auth-kFJb851CNTRL-example

Reusable keys can enroll multiple nodes but are dangerous if stolen. Anyone holding one can add devices to your tailnet until it expires or you revoke it. If you must use one, give it a short expiry and treat it like a root password.

Ephemeral nodes disappear after going offline and fit disposable jobs. A CI runner that lives for one build has no business leaving a permanent tailnet entry behind. Create the key with the ephemeral option and cleanup happens on its own.

Tags assign service identity during enrollment rather than attaching the node to a person. Combine them with any key type: the node’s identity becomes tag:ci or tag:server, and policy targets the role.

Classify your fleet

Classify a laptop, long-lived server, autoscaled runner, and CI job. Choose interactive login, one-off key, reusable key, or ephemeral enrollment for each.

My answers: laptop, interactive login. Long-lived server, one-off key with a tag. Autoscaled runners, ephemeral keys minted by automation, which is the next lessons’ topic. CI job, ephemeral tagged key, so each run enrolls fresh and vanishes after.

The failure mode to avoid: one reusable key pasted into five places “temporarily”. Six months later nobody remembers where, and revoking it breaks something unknown. Choose the key type that matches the machine’s lifespan.