{"slug":"manage-permissions-using-acls","title":"Manage permissions using ACLs","tags":["tailscale","access-control"],"agent_summary":"Last validated: Jan 5, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Manage permissions using ACLs\r\n\r\nLast validated: Jan 5, 2026\r\n\r\nTailscale now secures access to resources using [grants](https://tailscale.com/docs/features/access-control/grants), a next-generation access control policy syntax. Grants provide [all original ACL functionality plus additional capabilities](https://tailscale.com/docs/reference/grants-vs-acls).\r\n\r\nACLs will continue to work **indefinitely**; Tailscale will not remove support for this first-generation syntax from the product. However, Tailscale recommends [migrating to grants](https://tailscale.com/docs/reference/migrate-acls-grants) and using grants for all new tailnet policy file configurations because ACLs will not receive any new features.\r\n\r\nACLs are available on all plans, but [certain functionality might be restricted](https://tailscale.com/docs/features/access-control/acls#availability-by-plan) on some plans.\r\n\r\nACLs 101 - An Introduction to Access Control Lists \\| Tailscale Explained - YouTube\r\n\r\nTap to unmute\r\n\r\n[ACLs 101 - An Introduction to Access Control Lists \\| Tailscale Explained](https://www.youtube.com/watch?v=Jn8_Sh4r8d4) [Tailscale](https://www.youtube.com/channel/UCcdv38QxPjSMqbt5ffLhJLA)\r\n\r\nTailscale68.5K subscribers\r\n\r\nTailscale's [access control](https://tailscale.com/docs/features/access-control) methodology follows the [least privilege](https://tailscale.com/learn/principle-of-least-privilege) and [zero trust](https://tailscale.com/docs/concepts/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](https://tailscale.com/docs/features/tailnet-policy-file) using a [declarative huJSON syntax](https://tailscale.com/docs/reference/syntax/policy-file).\r\n\r\nACLs represent the traditional [network layer](https://en.wikipedia.org/wiki/Network_layer) approach to managing access within your tailnet, where you define [a set of devices or users](https://tailscale.com/docs/reference/targets-and-selectors) 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).\r\n\r\n```json\r\n{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [ ], // These sources (devices or users)\\\r\n \"dst\": [ : ], // can access these destination devices on their defined ports\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\nYou can use the [visual policy editor](https://tailscale.com/docs/features/visual-editor) to manage your tailnet policy file. Refer to the [visual editor reference](https://tailscale.com/docs/reference/visual-editor) for guidance on using the visual editor.\r\n\r\nWhen you first create your tailnet, the [default tailnet policy file](https://tailscale.com/docs/reference/examples/acls#allow-all-default-acl) enables communication between all devices within the tailnet. You can modify your policy file (including [editing ACLs](https://tailscale.com/docs/features/access-control/acls#edit-acls)) to fit your needs.\r\n\r\nACLs are deny-by-default, directional, locally enforced, and don't affect local network traffic.\r\n\r\n- **Deny-by-default**. Using a default deny policy prevents communication between devices without explicit access to each other. However, in the absence of an `acls` section in the tailnet policy file, Tailscale applies the [default allow all policy](https://tailscale.com/docs/reference/examples/acls#allow-all-default-acl).\r\n- **Directional**. Allowing a source to connect to a destination doesn't mean the destination can connect to the source (unless a policy explicitly enables it).\r\n- **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.\r\n- ACLs do not affect what a device can or cannot access on its local network.\r\n\r\nFor more information about Tailscale's approach to access control, refer to [RBAC like it was meant to be](https://tailscale.com/blog/rbac-like-it-was-meant-to-be).\r\n\r\nIf you don't define any access control policies, Tailscale applies the [default allow all ACL policy](https://tailscale.com/docs/reference/examples/acls#allow-all-default-acl). To deny all traffic, use an [empty object for the `acls` section](https://tailscale.com/docs/reference/examples/acls#deny-all) in your tailnet policy file.\r\n\r\n## [Edit ACLs](https://tailscale.com/docs/features/access-control/acls\\#edit-acls)\r\n\r\nYou can edit your tailnet's access rules by using the [Access controls](https://login.tailscale.com/admin/acls) page of the admin console, [GitOps for Tailscale ACLs](https://tailscale.com/docs/gitops), or the [Tailscale API](https://tailscale.com/docs/reference/tailscale-api). Refer to [Editing ACLs](https://tailscale.com/docs/features/tailnet-policy-file/manage-tailnet-policies) for more information.\r\n\r\nRefer to [tailnet policy file syntax](https://tailscale.com/docs/reference/syntax/policy-file) to create access control policies or the [sample ACLs](https://tailscale.com/docs/reference/examples/acls) for examples of common policies.\r\n\r\n## [Availability by plan](https://tailscale.com/docs/features/access-control/acls\\#availability-by-plan)\r\n\r\nACLs are available on all plans, but certain functionality might be restricted on some plans.\r\n\r\n| **Availability** | **On [all plans](https://tailscale.com/pricing)** | **On [the Premium and Enterprise plans](https://tailscale.com/pricing)** |\r\n| --- | --- | --- |\r\n| Access rules for... | - Any
- Tailscale IP
- Subnet CIDR Range
- Autogroups
- Groups
- Users
- Tags
- Hosts
- IP sets |\r\n| Access rules specifying... | - Ports
- Protocols | |\r\n| ACL sections for... | - `acl`
- `groups`
- `hosts`
- `tests`
- `tagOwners`
- `autoApprovers`
- `nodeAttrs`
- `postures` with default device posture attributes only

- `ipsets` | - `acl`
- `groups`
- `hosts`
- `tests`
- `tagOwners`
- `autoApprovers`
- `postures` with default, custom, and third-party attributes

- `ipsets` |\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"

Manage permissions using ACLs

\n

Last validated: Jan 5, 2026

\n

Tailscale now secures access to resources using grants, a next-generation access control policy syntax. Grants provide all original ACL functionality plus additional capabilities.

\n

ACLs will continue to work indefinitely; Tailscale will not remove support for this first-generation syntax from the product. However, Tailscale recommends migrating to grants and using grants for all new tailnet policy file configurations because ACLs will not receive any new features.

\n

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

\n

ACLs 101 - An Introduction to Access Control Lists | Tailscale Explained - YouTube

\n

Tap to unmute

\n

ACLs 101 - An Introduction to Access Control Lists | Tailscale Explained Tailscale

\n

Tailscale68.5K subscribers

\n

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.

\n

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

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

You can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor.

\n

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

\n

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

\n
    \n
  • Deny-by-default. Using a default deny policy prevents communication between devices without explicit access to each other. However, in the absence of an acls section in the tailnet policy file, Tailscale applies the default allow all policy.
    • \n
  • Directional. Allowing a source to connect to a destination doesn't mean the destination can connect to the source (unless a policy explicitly enables it).
    • \n
  • 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.
    • \n
  • ACLs do not affect what a device can or cannot access on its local network.
    • \n
\n

For more information about Tailscale's approach to access control, refer to RBAC like it was meant to be.

\n

If you don't define any access control policies, Tailscale applies the default allow all ACL policy. To deny all traffic, use an empty object for the acls section in your tailnet policy file.

\n

Edit ACLs

\n

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.

\n

Refer to tailnet policy file syntax to create access control policies or the sample ACLs for examples of common policies.

\n

Availability by plan

\n

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

\n

| Availability | On all plans | On the Premium and Enterprise plans |\r\n| --- | --- | --- |\r\n| Access rules for... | - Any
- Tailscale IP
- Subnet CIDR Range
- Autogroups
- Groups
- Users
- Tags
- Hosts
- IP sets |\r\n| Access rules specifying... | - Ports
- Protocols | |\r\n| ACL sections for... | - acl
- groups
- hosts
- tests
- tagOwners
- autoApprovers
- nodeAttrs
- postures with default device posture attributes only

- ipsets | - acl
- groups
- hosts
- tests
- tagOwners
- autoApprovers
- postures with default, custom, and third-party attributes

- ipsets |

\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}