Use OAuth clients for repeated automation

Repeated automation should not distribute one reusable device-enrollment credential to every environment.

A reusable auth key in five CI pipelines is five copies of the same secret, one expiry date, and no way to tell which pipeline enrolled which node. When it leaks, and shared long-lived secrets do leak, you rotate everything at once, in a hurry.

What an OAuth client changes

A Tailscale OAuth client receives limited scopes and tags. Automation uses its client secret to request fresh auth keys, then enrolls nodes with those short-lived keys.

Create the client in the admin console with only the auth keys scope and only the tags it may hand out, such as tag:ci. The client can mint keys, but never keys with broader power than its own scope and tags. That bound is the security win: a compromised CI system can enroll tag:ci nodes, not tag:server ones.

The minting flow

The automation exchanges its credentials for an API access token:

curl -s -d "client_id=$TS_CLIENT_ID" -d "client_secret=$TS_CLIENT_SECRET" \
  https://api.tailscale.com/api/v2/oauth/token

With the returned token, it calls the keys API to create a one-off, ephemeral, pre-tagged auth key, and passes that to enrollment:

sudo tailscale up --auth-key="$TS_MINTED_KEY" --advertise-tags=tag:ci

Each job gets its own key, used once, expiring fast. Nothing long-lived ever touches a runner.

Keep the OAuth secret in a vault, scope tags narrowly, and rotate the client if the secret is exposed. The secret is powerful, but it lives in exactly one place, your secret manager, instead of being copied around.

Design the lab flow

Design an enrollment flow for CI runners that creates one ephemeral tagged node per job and removes access when the job ends. With ephemeral keys, removal is free: the node evaporates once it goes offline. The audit story improves too, because every enrollment traces back to one client and one job.