![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Feb 2, 2026
\nTailscale now secures access to resources using grants, a next-generation access control policy syntax. Grants provide all original ACL functionality plus additional capabilities.
\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 and using grants for all new tailnet policy file configurations because ACLs will not receive any new features.
\nYou 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.
\nThis topic provides example access controls (ACLs) for common scenarios. For information about the syntax, refer to the tailnet policy syntax.
\n| Example | Description | Uses |\r\n| --- | --- | --- |\r\n| Allow all | The default tailnet policy that lets all devices within the tailnet access other devices in the tailnet. | ACLs, SSH |\r\n| Deny all | Deny all connections. | ACLs |\r\n| Users can access their own devices | All tailnet users can access devices they own unless another policy prevents it. | ACLs, SSH |\r\n| Resource-level access policies | Allow specific devices to access specific resources within the tailnet. | ACLs, hosts |\r\n| Restrict based on purpose (tags) | Allow specific devices to access specific resources within the tailnet using tags. | ACLs |\r\n| Restrict based on group | Manage access to resources using autogroups, custom groups, and provisioned groups. | ACLs, groups |\r\n| Restrict based on individual users | Manage access to resources for specific users. | ACLs |\r\n| Standard plan ACL | Use a basic standard plan that lets employees access their own devices and devices tagged with corp and lets admins access devices tagged with corp or prod. | ACLs, tag owners |\r\n| Access to an internal application (VPN) | Manage user access applications based on their job role. | ACLs, groups, tag owners |\r\n| Access to an internal application (VPN) with synced groups | Manage access to internal resources using groups synced to an identity provider. | ACLs, groups, tag owners |\r\n| Remote access to a production environment | Manage user access to the production environment based on their job role. | ACLs, groups, tag owners, tests |\r\n| VPC access (VPC peering) | Manage access to a virtual private cloud using access control lists. | ACLs, groups, tag owners, auto approvers |\r\n| Share access with a contractor | Allow a third-party contractor to access shared resources in the development environment. | ACLs, groups, tag owners |\r\n| Remote development | Manage access to a remote development environment. | ACLs, groups, tag owners |\r\n| Pair programming | Create a paired programming environment multiple engineers can connect to using SSH. | ACLs, tag owners |\r\n| CI/CD deployment pipeline | Manage access to resources based on job roles. | ACLs, groups, tag owners |\r\n| Monitoring access to applications | Allow a monitoring server to access all applications on common ports. | ACLs, groups, tag owners |\r\n| Application peering | Allow multiple cloud providers or applications to access each other. | ACLs, groups, tag owners |\r\n| Network microsegmentation | Allow access to network microsegments, but deny access between them. | ACLs, groups, tag owners, tests |
Prefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, SSH, autogroups |
\nWhen you first create your Tailscale network (known as a tailnet), Tailscale initializes it with a default allow all access policy to make it easy to connect to and use Tailscale without restricting any traffic in your network.
\nYou can reset your ACL policy file to the original default by deleting the existing policy file contents and selecting Reset to default. Policy file changes can also be reverted from the Configuration logs page of the admin console.
\nHere's a breakdown of what the default policy does:
\n--snat-subnet-routes=false (Linux only), then any devices on the same local network as the subnet router can also access all devices in the tailnet.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"*\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"*:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"ssh\": [\\\r\n {\\\r\n \"action\": \"check\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self\"\\\r\n ],\\\r\n \"users\": [\\\r\n \"autogroup:nonroot\",\\\r\n \"root\"\\\r\n ]\\\r\n }\\\r\n ],\r\n}\nOmitting the acls field from the tailnet policy file is equivalent to the default allow all policy. To deny all connections, use an empty object for the acls field in your policy file.
{} // Tailscale applies the default allow all policy if the acls section is empty.\nIn the default ACL, the ssh rule uses autogroup:self for the dst field andautogroup:nonroot in the users field. If you change the dst field fromautogroup:self to some other destination, such as an ACL tag, also consider replacingautogroup:nonroot in the users field. If you don't removeautogroup:nonroot from the users field, then anyone permitted by the src setting will be able to SSH in as any nonroot user on the dst device.
Prefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs |
\nYou can deny all connections in your tailnet by using an empty option for the acls field in your policy file. This configuration prevents all devices from communicating with each other. This configuration is not recommended for general use because nothing in the tailnet will work.
{\r\n \"acls\": []\r\n}\nOmitting the acls field from the tailnet policy file is not the equivalent of a \"deny all\" policy. Instead, Tailscale applies the default allow all policy, which allows all devices within the tailnet to access other devices in the tailnet.
Prefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, tags, tag owners |
\nThis example lets all users access their own devices. It is suitable for many use cases where you want to allow users to access their own devices, but not other devices in the tailnet.
\n{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, hosts |
\nYou can enable connectivity from one device or network to another using their IP addresses. Additionally, the hosts section lets you define a human-friendly name for an IP address or CIDR range, to make access rules more readable.
What this example does:
\n100.100.123.124 can access the device with the IP address 100.100.123.123.100.100.123.124 can access devices in the subnet 192.0.2.0/24 through a subnet router.frontend-server-01 can access devices in the subnet 192.0.2.0/24.frontend-server-01 can access the device with the hostname dev-network-01.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"100.100.123.124\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"100.100.123.123:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"100.100.123.124\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"192.0.2.0/24:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"frontend-server-01\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"192.0.2.0/24:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"frontend-server-01\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"dev-network-01:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"hosts\": {\r\n \"frontend-server-01\": \"100.100.123.123\",\r\n \"dev-network-01\": \"203.0.113.0/24\"\r\n }\r\n}\nWhen writing access control rules targeting resources behind a 4via6 subnet router, use the IPv6 CIDR or address as the destination, not the IPv4 address.
\nUse tailscale debug via to get the IPv6 CIDR.
Prefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, tags |
\nTags let you assign an identity to a device that is separate from human users, and use that identity as part of an ACL to restrict access. Tags should be used when adding servers to your Tailscale network, so that their access is based on their purpose, not based on which member of your operations team enrolled them.
\nWhat this example does:
\ntag:frontend can access devices tagged with tag:backend.tag:backend can access devices tagged with tag:logging.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"tag:frontend\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:backend:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"tag:backend\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\nYou can enable access to resources in your tailnet with autogroups, custom groups, or groups provisioned from supported identity providers.
\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, autogroups, tags |
\nAutogroups are built-in groups that automatically include users, destinations, or usernames with the same properties.
\nWhat this example does:
\nautogroup:member can access devices tagged with tag:frontend.autogroup:admin) can access devices tagged with tag:backend or tag:logging.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:admin\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:backend:*\",\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, autogroups, tags |
\nCustom groups let you define a shorthand for a group of users, which you can then use in access rules instead of listing users out explicitly.
\nWhat this example does:
\ngroup:engineering consists of alice@example.com and bob@example.com.group:engineering consists of amelie@example.com and carl@example.com.group:engineering can access devices tagged with tag:frontend or tag:backend.group:devops can access devices tagged with tag:frontend, tag:backend, or tag:logging.{\r\n \"groups\": {\r\n \"group:engineering\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ],\r\n \"group:devops\": [\\\r\n \"amelie@example.com\",\\\r\n \"carl@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:engineering\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\",\\\r\n \"tag:backend:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:devops\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\",\\\r\n \"tag:backend:*\",\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\nYou can use group provisioning from supported identity providers and avoid maintaining custom groups in your ACLs.
\n{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:engineering@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\",\\\r\n \"tag:backend:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:devops@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\",\\\r\n \"tag:backend:*\",\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, tags |
\nYou can enable access to resources based on individual users.
\nWhat this example does:
\ntag:frontend.tag:backend.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"amelie@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:frontend:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"bob@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:backend:*\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| All plans | ACLs, autogroups, tags, tag owners |
\nThis example provides remote access to corp and prod devices. It is suitable for many Standard plan use cases.
\nYour team can use Tailscale to access remote devices. In this scenario, all users can access their own remote devices, as well as any common corporate devices, such as servers, that are tagged. Only Tailscale Admins can access production devices. Admins can configure which devices are tagged. No corporate or production devices can access each other, and no shared users can access devices.
\nWhat this example does:
\ntag:corp.autogroup:admin) can access devices tagged with tag:prod.tag:corp and tag:prod.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:corp:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:admin\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:prod:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:corp\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:prod\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, tags, tag owners |
\nYou can use Tailscale to allow users to access internal applications, including both custom internal applications and third-party applications hosted internally. In this scenario, users in your tailnet can access applications based on their job role. The IT team can set up internal applications.
\nWhat this example does:
\ngroup:engineering can access the devices tagged with tag:engineering.group:finance can access the devices tagged with tag:finance.group:legal can access the devices tagged with tag:legal.tag:internal.autogroup:admin) (such as the IT team) can manage which devices are tagged with tag:engineering, tag:finance, tag:legal, and tag:internal.{\r\n \"groups\": {\r\n \"group:engineering\": [\\\r\n \"alice@example.com\"\\\r\n ],\r\n \"group:finance\": [\\\r\n \"bob@example.com\"\\\r\n ],\r\n \"group:legal\": [\\\r\n \"carl@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:engineering\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:engineering:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:finance\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:finance:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:legal\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:legal:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:internal:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:engineering\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:finance\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:legal\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:internal\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Enterprise | ACLs, groups, autogroups, tags, tag owners |
\nYou can use user and group provisioning to include groups synced from your identity provider in access rules. Tailscale treats synced group names as lowercase. They can include spaces, but not the @ symbol.
What this example does:
\ngroup:engineering@example.com can access the devices tagged with tag:engineering.group:finance team@example.com can access the devices tagged with tag:finance.group:Legal@example.com can access the devices tagged with tag:legal.tag:internal.autogroup:admin) (such as the IT team) can manage which devices are tagged with tag:engineering, tag:finance, tag:legal, and tag:internal.{\r\n \"groups\": {},\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:engineering@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:engineering:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:finance team@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:finance:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:legal@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:legal:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:internal:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:engineering\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:finance\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:legal\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:internal\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, autogroups, tags, tag owners, tests |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:dev).
Your DevOps, infrastructure, or SRE team can use Tailscale to access their sensitive and highly protected production environment. In this scenario, a DevOps team might be able to access the production environment, whereas other developers might only be able to access resources in a development environment. All developers are able to access monitoring tools, such as Grafana.
\nWhat this example does:
\ngroup:dev can access the devices tagged with tag:dev (such as license servers).autogroup:admin) (such as members of the DevOps team) can access the devices tagged with tag:prod (such as the production environment).tag:monitoring on ports 80 and 443 (such as monitoring dashboards).autogroup:admin) can manage which devices are tagged with tag:dev, tag:prod, and tag:monitoringtag:prod on port 80.tag:dev (but not devices tagged with tag:prod) on port 80.{\r\n \"groups\": {\r\n \"group:dev\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:dev\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:dev:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:admin\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:prod:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:monitoring:80,443\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:monitoring\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:dev\": [\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"tag:prod\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n },\r\n \"tests\": [\\\r\n {\\\r\n \"src\": \"carl@example.com\",\\\r\n \"accept\": [\\\r\n \"tag:prod:80\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"src\": \"alice@example.com\",\\\r\n \"accept\": [\\\r\n \"tag:dev:80\"\\\r\n ],\\\r\n \"deny\": [\\\r\n \"tag:prod:80\"\\\r\n ]\\\r\n }\\\r\n ]\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, autogroups, tags, tag owners, auto approvers |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:dev).
Your DevOps team can use Tailscale to allow developers to access existing internal applications running in a Virtual Private Cloud (VPC) on a private or hosted cloud provider. In this scenario, developers can access resources in the VPC, and the DevOps team is able to manage access to the VPC. VPCs can be peered to each other if they don't have overlapping IP ranges. To connect an existing subnet to your Tailscale network without installing Tailscale on every device, you can use a subnet router. Run a subnet router in the subnet, and advertise the routes so that Tailscale can route traffic for the subnet to the device for forwarding. For devices on a subnet to connect to devices in your tailnet, disable subnet route masquerading. You can also use auto approvers to automatically approve routes.
\nWhat this example does:
\nautogroup:admin) (such as the IT team) can access the devices tagged with tag:vpc-peering (for maintenance).group:dev can access devices in the subnets 192.0.2.0/24 and 198.51.100.0/24.192.0.2.0/24 can access the subnet 198.51.100.0/24 and vice versa (if subnet route masquerading is disabled).autogroup:admin) (such as the IT team) can manage which devices are tagged with tag:vpc-peering.autogroup:admin) and devices tagged with tag:vpc-peering can auto-approve routes for 192.0.2.0/24 and 198.51.100.0/24.{\r\n \"groups\": {\r\n \"group:dev\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:admin\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:vpc-peering:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:dev\",\\\r\n \"192.0.2.0/24\",\\\r\n \"198.51.100.0/24\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"192.0.2.0/24:*\",\\\r\n \"198.51.100.0/24:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:vpc-peering\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n },\r\n \"autoApprovers\": {\r\n \"routes\": {\r\n \"192.0.2.0/24\": [\\\r\n \"tag:vpc-peering\",\\\r\n \"autogroup:admin\"\\\r\n ],\r\n \"198.51.100.0/24\": [\\\r\n \"tag:vpc-peering\",\\\r\n \"autogroup:admin\"\\\r\n ]\r\n }\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, autogroups, tags, tag owners |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:dev).
Your development team can use Tailscale to share access to specific resources, such as a database or a hosted code repository, with a contractor. In this scenario, developers can access internal development resources. Specific devices can be shared with a contractor as part of their job.
\nWhat this example does:
\ngroup:dev can access devices tagged with tag:dev (such as package registries and databases)tag:dev (that have been shared with them).{\r\n \"groups\": {\r\n \"group:dev\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:dev\",\\\r\n \"autogroup:shared\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:dev:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:dev\": [\\\r\n \"group:dev\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, autogroups, tags, tag owners |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:dev).
Your development team can use Tailscale as part of their remote development setup. In this scenario, a developer might have a local device, like a laptop, and use it to access a remote workstation, hosted in the cloud or hosted on another device in their network. This is useful if you're accessing a workstation with more processing power, for example, for machine learning or for building. You might also use a remote code environment like GitHub Codespaces, Gitpod, or Coder. From your development environment, you might access a license server, a package registry, a production database, or another development or build resource. You might also access a self-hosted or private code repository.
\nWhat this example does:
\ngroup:dev can access devices tagged with tag:dev (such as package registries and databases).group:dev can manage which devices are tagged with tag:dev.{\r\n \"groups\": {\r\n \"group:dev\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"autogroup:member\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"autogroup:self:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:dev\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:dev:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:dev\": [\\\r\n \"group:dev\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, tags, tag owners |
\nYou can modify this example to work on the Standard plan by using autogroup:member and autogroup:admin instead of named users.
Your development team can use Tailscale to pair program on the same device remotely. In this scenario, two or more developers can use SSH to connect to a corporate device, such as a virtual machine (VM), and share a terminal (such as a tmux session).
What this example does:
\ntag:pair-programming on port 22 (for SSH).tag:pair-programming.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:pair-programming:22\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:pair-programming\": [\\\r\n \"bob@example.com\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, tags, tag owners |
\nYour DevOps or infrastructure team can use Tailscale to restrict access to your deployment pipeline. In this scenario, developers can access your development tools, such as your code repository. Then, an automated CI/CD pipeline builds and deploys code. The DevOps team can access the deployment pipeline and production environment.
\nWhat this example does:
\ngroup:dev can access the devices tagged with tag:dev (such as code repositories and license servers).group:devops can access the devices tagged with tag:ci (such as the build tooling) and tag:prod (such as the production environment).group:devops can manage which devices are tagged with tag:dev, tag:ci, and tag:prod.tag:ci can manage which device are tagged with tag:prod and tag:dev (to apply tags as part of the deployment pipeline).{\r\n \"groups\": {\r\n \"group:dev\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ],\r\n \"group:devops\": [\\\r\n \"carl@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:dev\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:dev:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:devops\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:ci:*\",\\\r\n \"tag:prod:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:ci\": [\\\r\n \"group:devops\"\\\r\n ],\r\n \"tag:dev\": [\\\r\n \"group:devops\",\\\r\n \"tag:ci\"\\\r\n ],\r\n \"tag:prod\": [\\\r\n \"group:devops\",\\\r\n \"tag:ci\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, tags, tag owners |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:devops).
Your DevOps team can use Tailscale to query logs from services in your network and report these as part of your monitoring tooling. In this scenario, your monitoring server (such as Prometheus) can access all applications in your network on common ports.
\nWhat this example does:
\ntag:monitoring can access services on ports 80, 443, 9100.tag:monitoring can access services tagged tag:logging.group:devops can access devices tagged with tag:monitoring and tag:logging.group:devops can manage which devices are tagged with tag:monitoring and tag:logging.{\r\n \"groups\": {\r\n \"group:devops\": [\\\r\n \"carl@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"tag:monitoring\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"*:80,443,9100\",\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:devops\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:monitoring:*\",\\\r\n \"tag:logging:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:monitoring\": [\\\r\n \"group:devops\"\\\r\n ],\r\n \"tag:logging\": [\\\r\n \"group:devops\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, tags, tag owners |
\nYou can modify this example to work on the Standard plan by using autogroup:member instead of a custom group (group:infra).
Your infrastructure team can use Tailscale to connect applications or services running in multiple cloud providers or SaaS applications together. In this scenario, one application can connect with another application in your network, for example, to stream from one database to another, such as with\r\nMaterialize.
\nWhat this example does:
\ntag:database can access other devices tagged with tag:database.tag:gcp and tag:aws can access devices tagged with tag:database, but not vice versa.group:infra can manage which devices are tagged with tag:database, tag:gcp, and tag:aws.{\r\n \"groups\": {\r\n \"group:infra\": [\\\r\n \"carl@example.com\"\\\r\n ]\r\n },\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"tag:database\",\\\r\n \"tag:gcp\",\\\r\n \"tag:aws\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:database:*\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:database\": [\\\r\n \"group:infra\"\\\r\n ],\r\n \"tag:gcp\": [\\\r\n \"group:infra\"\\\r\n ],\r\n \"tag:aws\": [\\\r\n \"group:infra\"\\\r\n ]\r\n }\r\n}\nPrefer grant examples
\nGrants provide all the capabilities of ACLs plus application-layer permissions. For modern access control patterns, refer to the grant examples.
\n| Plan availability | Features |\r\n| --- | --- |\r\n| Personal, Premium, and Enterprise | ACLs, groups, tags, tag owners, tests |
\nNetwork microsegmentation is a security technique that divides network devices, access, and communications into unique logical units. There are many use cases for this—segmenting data centers, virtual networks, customer deployments, and others. Each microsegment is a logical unit that cannot access other microsegments. In some cases, you might still need a support team or tagged devices that can access all segments.
\nWhat this example does:
\ngroup:support can access devices tagged tag:segment-abc and tag:segment-xyz on port 443.tag:support can access devices tagged tag:segment-abc and tag:segment-xyz on port 443.group:support will still be able to access devices tagged tag:segment-abc and tag:segment-xyz on port 443.tag:support will still be able to access devices tagged tag:segment-abc and tag:segment-xyz on port 443.tag:segment-abc are denied access to devices tagged tag:segment-xyz on port 443.tag:segment-xyz are denied access to devices tagged tag:segment-abc on port 443.{\r\n \"acls\": [\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"group:support\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:segment-abc:443\",\\\r\n \"tag:segment-xyz:443\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"action\": \"accept\",\\\r\n \"src\": [\\\r\n \"tag:support\"\\\r\n ],\\\r\n \"dst\": [\\\r\n \"tag:segment-abc:443\",\\\r\n \"tag:segment-xyz:443\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"tests\": [\\\r\n {\\\r\n \"src\": \"group:support\",\\\r\n \"accept\": [\\\r\n \"tag:segment-abc:443\",\\\r\n \"tag:segment-xyz:443\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"src\": \"tag:support\",\\\r\n \"accept\": [\\\r\n \"tag:segment-abc:443\",\\\r\n \"tag:segment-xyz:443\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"src\": \"tag:segment-abc\",\\\r\n \"deny\": [\\\r\n \"tag:segment-xyz:443\"\\\r\n ]\\\r\n },\\\r\n {\\\r\n \"src\": \"tag:segment-xyz\",\\\r\n \"deny\": [\\\r\n \"tag:segment-abc:443\"\\\r\n ]\\\r\n }\\\r\n ],\r\n \"groups\": {\r\n \"group:support\": [\\\r\n \"alice@example.com\",\\\r\n \"bob@example.com\"\\\r\n ]\r\n },\r\n \"tagOwners\": {\r\n \"tag:support\": [\\\r\n \"autogroup:admin\"\\\r\n ]\r\n }\r\n}\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}