Organize people and services

Policies become difficult to review when every rule repeats individual email addresses and IPs.

Three devices and one admin? Raw identities are fine. Ten people and thirty servers? Every hire and every new machine means editing every rule that mentions them. The fix is a layer of names.

Groups for people

Groups collect users. Define them once, reference them everywhere:

{
  "groups": {
    "group:operators": ["[email protected]", "[email protected]"]
  }
}

Now a grant can say "src": ["group:operators"]. When someone joins the team, you edit one line, and every rule that references the group follows.

Tags for services

Tags describe non-human devices by role, such as tag:server or tag:database. A tagged device is not owned by whoever enrolled it. Its identity is the tag. This matters for servers: the machine should keep working, and keep its policy identity, after the person who set it up leaves.

tagOwners controls who may assign each tag, because assigning a powerful tag changes authorization:

{
  "tagOwners": {
    "tag:server": ["group:operators"],
    "tag:database": ["group:operators"]
  }
}

If anyone could apply tag:database to their own laptop, they would inherit every grant that targets databases. Tag assignment is a privileged operation. Treat the owner list accordingly.

Autogroups for built-in roles

Autogroups select built-in sets such as members or administrators. autogroup:member means every user in the tailnet, autogroup:admin the admins, autogroup:self a device’s own user. They cover policies like “everyone may reach the internal wiki” without maintaining a group by hand.

Set up the lab

Create a group:operators group and let only that group own tag:server. Keep human laptops user-owned instead of tagging everything. A laptop’s identity should be its person. That is what makes user-based rules like “Flavio may SSH to servers” meaningful when you read them a year from now.