Tailscale device tags are identities, not deployment labels
Tags in Tailscale give a device an identity separate from the user who enrolled it. The tag then participates in access control, grants, subnet routers, and other policy decisions. That makes a tag an authorization object. Treating tag:prod as a harmless deployment label can give a device more access than its owner intended.
The policy file must define who can apply each tag. A tag owner can create devices with that identity, so ownership should be narrow and tied to an accountable team. Review tag names for purpose and environment, and avoid a single broad tag that spans build runners, monitoring jobs, and administrator workstations. Tailscale parses tag names case-insensitively, which means tag:Prod and tag:prod should not be treated as distinct security groups.
Tailscale's documentation describes tags as device identities that work with ACLs and grants. The recommended direction for new policy is grants, which combine network-layer and application-layer permissions. A grant that matches a device tag applies to every device that can carry that tag. Review that full population when the rule changes.
Review enrollment and ownership together
Check the tag owner list, the pre-authorized identity path, key expiry settings, and the devices currently carrying each tag. A tag can outlive the individual who enrolled the device, so the review should have an owner outside that individual's account. When an application, runner, or appliance is retired, remove its device identity and any grants that match it.
For sensitive services, add a second condition that reflects a real trust boundary, such as a distinct tag for the service tier or an application capability checked by the service. A network grant for tag:worker to tag:database should not imply that every worker may invoke every database role. The application still has to authenticate the workload and authorize the operation.
Do not confuse tags with user identity
A tagged device does not authenticate the person using it. If an administrative session runs on a tagged host, the tailnet policy may see the host identity while the human identity is handled elsewhere. Design logs and incident response around that distinction. Record which tag authorized a connection, which workload produced the request, and which user or service account authenticated to the application.
Review ACLs that predate the move to grants. Tailscale recommends grants for new policy work, while legacy ACLs can remain in the same file. A migration that adds a new grant without reviewing the old ACL can leave a broader path in place. Search for duplicate access, wildcard targets, and administrator groups that can reach tagged systems.
Test policy changes before broad rollout
Use the policy test or preview facilities available in the deployment to evaluate representative source identities. Test a user account, a tagged service, an exit node, and a subnet router separately. Confirm that removing a grant blocks the intended path and that a device with a stale tag cannot retain the old access.
Tag-based access is useful because it makes machine identity explicit. That benefit depends on tags being stable, narrowly owned, and tied to a reviewed workload. Once a tag becomes a convenience label, the policy can no longer tell which machines are trusted for which purpose.
Top comments (0)