Move from connectivity to authorization

Joining the tailnet answers “who or what is this?” Access policy answers “what may it reach?” Those are different decisions.

Up to now, everything in your practice tailnet could reach everything. That is because new tailnets ship with a permissive starter policy, so the first experience works without configuration:

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip":  ["*"]
    }
  ]
}

Every device may reach every device on every port. Fine for a two-device experiment. Wrong for anything you plan to keep.

Deny by default

Tailscale access controls are deny by default once you replace the permissive starter policy. Remove that wildcard grant and no packet flows anywhere until a rule allows it.

There is no “block” rule type. Rules grant access; they do not add explicit deny entries. Anything not granted is denied. This model has one big consequence: you can read a policy and know exactly what is reachable. There is no rule-ordering puzzle where a later deny overrides an earlier allow.

What a grant contains

Modern policies use grants for network and application capabilities. A grant names sources, destinations, and allowed IP protocols or ports:

{
  "src": ["[email protected]"],
  "dst": ["tag:server"],
  "ip":  ["tcp:22"]
}

Sources and destinations can be users, groups, tags, or autogroups. The ip field narrows the grant to protocols and ports. We will write and apply a real one in the next lesson.

Start from a sentence

Before touching JSON, write one sentence describing who should reach the lab server, on which port, and why. Everything else should remain ungranted.

Mine reads: “My user may reach TCP port 22 on servers tagged tag:server, to administer them over SSH.” If you cannot write the sentence, you are not ready to write the rule. The sentence forces you to name the source, the destination, and the purpose, which is exactly what a reviewer will ask about later.