GuidesPreview
Access control
Decide which users and devices can reach which devices, using tags, groups and grants.
Access control decides who can reach what inside a network. You describe it with tags, groups and grants, write it in the dashboard's policy editor, and check it with the policy tester before you save. Every device then enforces it.
How access is decided
Access is granted, never assumed: a connection goes through only when a grant allows it. If no grant allows a connection, it's blocked.
A policy applies to the devices in your network. Networks of other organisations are fully isolated from yours.
To see what your network allows right now, open the policy editor or ask the policy tester.
Tags
A tag says what a device is for, such as server, database or ci. Grants refer to tags instead of individual devices, so a new server gets the right access as soon as it's tagged.
Tag a device in the dashboard, or have it get its tags as it joins by using a tagged auth key. Tagged keys suit servers and automation: every device that joins with the key gets the key's tags.
Groups
A group is a named set of users, such as engineering or support. Grants that name a group follow its membership: add someone to the group and they get its access; remove them and they lose it.
Grants
A grant allows a source to reach a destination. Grants written in terms of groups and tags keep working as people and machines come and go.
| Goal | The grant, in words |
|---|---|
| Engineers can reach every server | The engineering group can reach devices tagged server. |
| CI can reach production | Devices tagged ci can reach devices tagged prod. |
| Support can reach the helpdesk machines | The support group can reach devices tagged helpdesk. |
| Staff can use exit nodes | The staff group can reach internet, through approved exit nodes. |
| Everyone can reach the office printers | Everyone can reach the office subnet (cidr:10.0.0.0/24), through its subnet router. |
Enforced on both ends
Both devices in a connection enforce the policy: the one that starts the connection and the one that receives it. Traffic gets through only when both agree it's allowed, so a single misconfigured or compromised device can't open access on its own.
A grant works in the direction it's written. Replies to a connection it allows come back on their own, but the other device can't start a connection of its own unless a grant lets it: with a grant from laptop to server, the laptop can ping the server and get its answer, while the server can't ping the laptop.
Relays aren't involved in the decision. They only forward encrypted packets and never see what's inside.
Test before you save
The policy tester answers questions such as "can this user reach this device?" for the policy you're editing, before you save it. Test the access you're adding and, just as important, the access that must stay blocked.
Approvals
Some changes need an admin's approval before they take effect:
| What | When approval is needed |
|---|---|
| Subnet routes | Always. See Subnet routes. |
| Exit nodes | Always. See Exit nodes. |
| New devices | If an admin requires device approval. |
| New users | If an admin requires user approval. |
Workflow
Tag your devices
Tag devices by role in the dashboard, or join servers with tagged auth keys.
Group your people
Put people who need the same access in the same group.
Write grants
In the dashboard's policy editor, give groups and tags access to tags.
Test
Check the cases that matter with the policy tester, including the ones that must stay blocked.
Save
Every device enforces the new policy, and the change is recorded in the audit log.