Device and user approval

Make new machines and users wait for an administrator with the device and user approval switches, cap key expiry, and approve from the CLI or API.

By default any node that presents a valid pre-auth key or completes a login joins the tailnet at once, and any user that logs in through OpenID Connect is created ready to register nodes. Two tailnet-wide switches put an administrator between those steps, following Tailscale’s device approval and user approval:

Both are off on a fresh server and after an upgrade; everything that existed before the switches did counts as approved. A third switch, postureIdentityOn, belongs to device trust and lets the server collect serial numbers from clients.

Settings

slopscale settings get
slopscale settings set --devices-approval=true
slopscale settings set --users-approval=true

Through the API, GET and POST /api/v1/settings with {"devicesApprovalOn": true}; the v2 API reads and patches the same values on /api/v2/tailnet/-/settings. Both need the feature_settings scope, which the owner and admins hold.

Switching a setting off approves every node or user that was waiting, so nothing stays stuck behind a requirement that no longer exists.

An invited user is created approved whatever usersApprovalOn says: the administrator who sent the invitation already vouched for the address, so making them wait again would ask the same question twice.

Key expiry

The same endpoint carries the tailnet’s key expiry, following Tailscale’s key expiry: keyExpiryDays caps how long a login stays valid. A client that asks for longer is shortened to it, and a login that asks for nothing gets it. It applies to the next login of each node, never to tagged nodes, and does not touch a node whose expiry an administrator disabled. Zero, the default, leaves the config file’s node.expiry and the client in charge; the response reports that file value as defaultKeyExpiryDays.

slopscale settings set --key-expiry-days 90

The v2 API exposes it as devicesKeyDurationDays. The console’s Settings page has it under Key expiry, next to a read-only Server card showing the build, addresses, DERP regions and config file values from GET /api/v1/server.

Devices

A node waiting for approval is registered and keeps its address, but it gets no peers, no peer sees it and its packet filter is empty. The Tailscale client shows it as needing machine authorization (tailscale status reports “Machine is not yet approved”), a health message, “This device is waiting for approval”, says why with a link to the console’s machines page, and the node picks up the approval live, without logging in again.

slopscale nodes list           # the Approved column reads "pending"
slopscale nodes approve --identifier 7
slopscale nodes approve --identifier 7 --revoke

Through the API, POST /api/v1/node/{id}/approve, with {"approved": false} to withdraw the approval; the node object carries approved and approvedAt. The v2 API’s POST /api/v2/device/{id}/authorized does the same, with authorized: false withdrawing, and the device object’s authorized field reflects it.

A pre-auth key is preauthorized unless created otherwise, so keys minted for automation keep working when device approval is switched on. A key that should not bypass approval is created with --preauthorized=false ("preauthorized": false on POST /api/v1/preauthkey, or the preauthorized capability of the v2 keys API).

slopscale preauthkeys create --user 1 --preauthorized=false

Users

A user waiting for approval shows as pending in slopscale users list, with approved: false in the v1 user object and "status": "needs-approval" in the v2 one. A login attempt by such a user is refused with a message that the account awaits approval; the user exists, so an administrator can find and approve them.

slopscale users approve --name alice
slopscale users approve --name alice --revoke

Through the API, POST /api/v1/user/{id}/approve, with {"approved": false} to withdraw; the v2 API’s POST /api/v2/users/{id}/approve, /suspend and /restore map onto the same state. Withdrawing a user’s approval also withdraws every node the user owns; approving the user again brings the nodes back unless device approval is on, in which case each node waits its own turn. Tagged nodes belong to their tags and are never affected by a user’s approval.