Test policy before trusting it

A valid policy can still grant the wrong access. Policy tests record examples that must continue to pass or fail.

The policy syntax checker catches typos. It cannot catch a rule that is syntactically perfect and grants your intern access to the production database. Tests encode intent, and intent is exactly what syntax checking cannot see.

Write the tests

Tailscale policy files support a tests section. Each test names a source, then lists connections that must be allowed and connections that must be denied:

{
  "tests": [
    {
      "src": "flavio@example.com",
      "accept": ["tag:server:22"],
      "deny": ["tag:server:5432"]
    },
    {
      "src": "anna@example.com",
      "deny": ["tag:server:22"]
    }
  ]
}

Test that the operator can reach SSH, that an ordinary member cannot reach it, and that neither identity receives an unrelated port. The tests run when you save the policy. A failing test blocks the save, so the bad policy never goes live.

Negative tests carry the weight

The deny entries are the valuable ones. An accept test fails loudly the moment someone needs the access, because their connection stops working. A missing deny fails silently: the unwanted access exists, nobody notices, and it waits there until someone finds it.

Every time you grant something narrow, add a deny test for the broader thing you deliberately did not grant.

Break it on purpose

Add at least one expected-accept and one expected-deny case for the lab server, then deliberately break a rule and confirm validation catches it.

Change tcp:22 to tcp:* in your grant and try to save. Your deny test for port 5432 should fail and refuse the save. That refusal is the whole point: a future edit, made by a tired version of you six months from now, cannot silently broaden access past what the tests pin down.

Keep tests beside the policy. Review the effective change before saving, especially when changing tags or broad selectors.