Manage permissions using ACLs

Tailscale’s access control methodology follows the least privilege and zero trust principles. There are two ways to define access controls for your tailnet: access control lists (ACLs) and grants. Both methods follow a deny-by-default principle and are defined in the tailnet policy file using a declarative huJSON syntax.

ACLs represent the traditional network layer (layer 3) approach to managing access within your tailnet, where you define a set of devices or users who can access ports on other devices. Each ACL you create must define a source and a destination. They let you precisely define access controls for users and devices on your Tailscale network (known as a tailnet).

{
    "acls": [
    {
        "action": "accept",
        "src": [ <list-of-sources> ], // These sources (devices or users)
        "dst": [ <destination>:<port> ], // can access these destination devices on their defined ports
    }
  ]
}

When you first create your tailnet, the default tailnet policy file allows communication between all devices within the tailnet. You can modify your policy file (including editing ACLs) to fit your needs.

ACLs are deny-by-default, directional, locally enforced, and don't affect local network traffic.

• Deny-by-default. Using a default deny policy prevents communication between devices without explicit access to each other.
• Directional. Allowing a source to connect to a destination doesn't mean the destination can connect to the source (unless a policy explicitly allows it).
• Locally enforced. A device enforces incoming connections based on the access rules distributed to all devices in your tailnet. Rule enforcement happens on each device directly, without further involvement from Tailscale's coordination server.
• ACLs do not affect what a device can or cannot access on its local network.

To learn more about Tailscale's approach to access control, read RBAC like it was meant to be.

Edit ACLs

You can edit your tailnet's access rules by using the Access Controls page of the admin console, GitOps for Tailscale ACLs, or the Tailscale API. Refer to Editing ACLs for more information.

Refer to ACL syntax to learn about creating access control policies or the sample ACLs for examples of common policies.

Availability by plan

ACLs are available on all plans, but certain functionality might be restricted on some plans.