Get started
Login
© 2024

Manage permissions using ACLs

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

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 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.

Availability

On all plans

On the Personal, Personal Plus, Premium, and Enterprise plans

Access rules for...
  • Any
  • Tailscale IP
  • Subnet CIDR Range
  • Autogroups
  • Tags
  • Hosts
  • IP sets
  • Any
  • Tailscale IP
  • Subnet CIDR Range
  • Autogroups
  • Groups
  • Users
  • Tags
  • Hosts
  • IP sets
Access rules specifying...
  • Ports
  • Protocols
    ACL sections for...
    • acl
    • hosts
    • tests
    • tagOwners
    • autoApprovers
    • nodeAttrs
    • postures with default device posture attributes only

    • ipsets
    • acl
    • groups
    • hosts
    • tests
    • tagOwners
    • autoApprovers
    • ssh for Tailscale SSH

    • nodeAttrs for Tailscale Funnel

    • postures with default, custom, and third-party attributes (Personal, Personal Plus, and Enterprise plans only)

    • ipsets

    Last updated Nov 27, 2024