Docs / Admin

ACL samples

This article provides sample ACLs for common scenarios. For information about the syntax, see Tailscale policy syntax.

Allow all (default ACL)

When you first create your Tailscale network, it gets initialized with a default “allow all” access policy. This makes it easy to connect to and use Tailscale, and does not restrict any traffic in your network.

What this ACL does:

  • All devices signed into the network can access all other devices

If you have a subnet router initialized with --snat-subnet-routes=false, then any devices on the same local network as the subnet router can also access all devices on the tailnet.

If you have a device shared from another network in your network, then that device cannot access any devices on the tailnet. The device can only respond to incoming connections from the network.

{
  "acls": [
    { "action": "accept", "src": ["*"], "dst": ["*:*"] },
  ],
}

Your 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. No corporate devices can access each other, and no shared users can access devices.

What this ACL does:

  • All employees can access their own devices
  • All employees can access corporate devices tagged tag:corp
  • All employees can manage which devices are tagged with tag:corp
{
   "acls": [
    // all employees can access their own devices
    { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:self:*"] },
    // all employees can access devices tagged tag:corp
    { "action": "accept", "src": ["autogroup:members"], "dst": ["tag:corp:*"] },
   ],
  "tagOwners": {
    // all employees can manage which devices are tagged tag:corp
    "tag:corp": ["autogroup:members"],
   },
 }

Remote development

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.

What this ACL does:

  • All employees can access their own devices
  • Members of the development team group:dev can access devices tagged tag:dev, such as package registries and databases
  • The development team group:dev can manage which devices are tagged with tag:dev
{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["[email protected]", "[email protected]",],
  },
  "acls": [
     // all employees can access their own devices
    { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:self:*"] },
    // users in group:dev can access devices tagged tag:dev
    { "action": "accept", "src": ["group:dev"], "dst": ["tag:dev:*"] },
  ],
  "tagOwners": {
    // users in group:dev can apply the tag tag:dev
    "tag:dev": ["group:dev"],
  },
}

Remote access to production environment

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.

What this ACL does:

  • All employees can access their own devices, such as remote workstations
  • Members of the development team group:dev can access the devices tagged tag:dev, such as license servers
  • Members of the DevOps team group:devops can access the devices tagged tag:prod, such as the production environment
  • All employees can access devices tagged tag:monitoring on ports 80 and 443, such as monitoring dashboards
  • The DevOps team group:devops can manage which devices are tagged with tag:dev, tag:prod, and tag:monitoring
  • Tests ensure that if ACLs are updated, Carl will still be able to access devices tagged tag:prod on port 80, and that Alice will be able to access devices tagged tag:dev but not tag:prod on port 80
{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["[email protected]", "[email protected]",],
    // Carl is in group:devops
    "group:devops": ["[email protected]",],
  },
  "acls": [
    // all employees can access their own devices
    { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:self:*"] },
    // users in group:dev can access devices tagged tag:dev
    { "action": "accept", "src": ["group:dev"], "dst": ["tag:dev:*"] },
    // users in group:devops can access devices tagged tag:prod
    { "action": "accept", "src": ["group:devops"], "dst": ["tag:prod:*"] },
     // all employees can access devices tagged tag:monitoring on
     // ports 80 and 443
    { "action": "accept", "src": ["autogroup:members"], "dst": ["tag:monitoring:80,443"] },
  ],
  "tagOwners": {
     // users in group:devops can apply the tag tag:monitoring
    "tag:monitoring": ["group:devops"],
    // users in group:devops can apply the tag tag:dev
    "tag:dev": ["group:devops"],
    // users in group:devops can apply the tag tag:prod
    "tag:prod": ["group:devops"],
  },
  "tests": [
    {
      "src": "[email protected]",
      // test that Carl can access devices tagged tag:prod on port 80
      "accept": ["tag:prod:80"],
    },
    {
      "src": "[email protected]",
      // test that Alice can access devices tagged tag:dev on port 80
      "accept": ["tag:dev:80"],
      // test that Alice cannot access devices tagged tag:prod on port 80
      "deny": ["tag:prod:80"],
    },
  ],
}

Pair programming

Your development team can use Tailscale to pair program on the same device remotely. In this scenario, two or more developers can SSH to a corporate device, such as a VM, and share a terminal, for example a tmux session

What this ACL does:

  • Users Alice and Bob can access the corporate device tagged tag:pair-programming on port 22, for SSH
  • Bob can manage which devices are tagged tag:pair-programming
{
  "acls": [
    // Alice and Bob can access devices tagged tag:pair-programming on
    // port 22
    { "action": "accept", "src": ["[email protected]", "[email protected]"], "dst": ["tag:pair-programming:22"] },
  ],
  "tagOwners": {
     // Bob can apply the tag tag:pair-programming
    "tag:pair-programming": ["[email protected]"],
  },
}

CI/CD deployment pipeline

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

What this ACL does:

  • Members of the development team group:dev can access the devices tagged tag:dev, such as code repositories and license servers
  • Members of the DevOps team group:devops can access the devices tagged tag:ci, such as the build tooling; and tag:prod, such as the production environment
  • The DevOps team group:devops can manage which devices are tagged with tag:dev, tag:ci, and tag:prod
  • The tag tag:ci can manage which device are tagged tag:prod and tag:dev, to apply tags as part of the deployment pipeline
{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["[email protected]", "[email protected]",],
    // Carl is in group:devops
    "group:devops": ["[email protected]",],
  },
  "acls": [
    // users in group:dev can access devices tagged tag:dev
    { "action": "accept", "src": ["group:dev"], "dst": ["tag:dev:*"] },
    // users in group:devops can access devices tagged tag:ci or
    // tagged tag:prod
    { "action": "accept", "src": ["group:devops"], "dst": ["tag:ci:*", "tag:prod:*"] },
  ],
  "tagOwners": {
    // users in group:devops can apply the tag tag:ci
    "tag:ci": ["group:devops"],
    // users in group:devops or devices tagged tag:ci can apply the tag tag:dev
    "tag:dev": ["group:devops", "tag:ci"],
    // users in group:devops or devices tagged tag:ci can apply the tag tag:prod
    "tag:prod": ["group:devops", "tag:ci"],
  },
}

Monitoring access to applications

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, all applications in your network can be accessed by your monitoring server, such as Prometheus, on common ports.

What this ACL does:

  • Devices tagged tag:monitoring can access services on ports 80, 443, 9100
  • Devices tagged tag:monitoring can access services tagged tag:logging
  • The DevOps team group:devops can access devices tagged with tag:monitoring and tag:logging
  • The DevOps team group:devops can manage which devices are tagged with tag:monitoring and tag:logging
{
  "groups": {
    // Carl is in group:devops
    "group:devops": ["[email protected]",],
  },
  "acls": [
    // devices tagged tag:monitoring can access all devices in the network on
    // ports 80, 443, and 9100, and devices tagged tag:logging on all ports
    { "action": "accept", "src": ["tag:monitoring"], "dst": ["*:80,443,9100", "tag:logging:*"] },
    // users in group:devops can access devices tagged tag:monitoring and
    // tag:logging
    { "action": "accept", "src": ["group:devops"], "dst": ["tag:monitoring:*", "tag:logging:*"] },
  ],
  "tagOwners": {
    // users in group:devops can apply the tag tag:monitoring
    "tag:monitoring": ["group:devops"],
    // users in group:devops can apply the tag tag:logging
    "tag:logging": ["group:devops"],
  },
}

Access to an internal application (VPN)

Your IT team 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 network can access applications based on their job role. The IT team can set up internal applications.

What this ACL does:

  • Members of the engineering team group:engineering can access the devices tagged tag:engineering
  • Members of the finance team group:finance can access the devices tagged tag:finance
  • Members of the legal team group:legal can access the devices tagged tag:legal
  • All employees can access the devices tagged tag:internal
  • The IT team group:it can manage which devices are tagged with tag:engineering, tag:finance, tag:legal, and tag:internal
{
  "groups": {
    // Alice is in group:engineering
    "group:engineering": ["[email protected]",],
    // Bob is in group:finance
    "group:finance": ["[email protected]",],
    // Carl is in group:legal
    "group:legal": ["[email protected]",],
    // Dave is in group:it
    "group:it": ["[email protected]",],
  },
  "acls": [
    // users in group:engineering can access devices tagged tag:engineering
    { "action": "accept", "src": ["group:engineering"], "dst": ["tag:engineering:*"] },
    // users in group:finance can access devices tagged tag:finance
    { "action": "accept", "src": ["group:finance"], "dst": ["tag:finance:*"] },
    // users in group:legal can access devices tagged tag:legal
    { "action": "accept", "src": ["group:legal"], "dst": ["tag:legal:*"] },
    // all employees can access devices tagged tag:internal
    { "action": "accept", "src": ["autogroup:members"], "dst": ["tag:internal:*"] },
  ],
  "tagOwners": {
    // users in group:it can apply the tag tag:engineering
    "tag:engineering": ["group:it"],
    // users in group:it can apply the tag tag:finance
    "tag:finance": ["group:it"],
    // users in group:it can apply the tag tag:legal
    "tag:legal": ["group:it"],
    // users in group:it can apply the tag tag:internal
    "tag:internal": ["group:it"],
  },
}

Application allowlisting for third-party SaaS application (IP allowlisting)

Your IT team can use Tailscale to allow users access to third-party hosted applications, where access is restricted using IP application allowlisting. In this scenario, traffic for a certain application, www​.example-saas-app.com, is allowed for your organization’s resources only if coming from a known set of fixed IP addresses. You can host an exit node in your network to route all traffic leaving your network, and use that node’s IP address as part of an application allowlist. You can also use auto approvers so that exit nodes are automatically approved.

What this ACL does:

  • Members of the IT team group:it can access the devices tagged tag:application-exit-node, for maintenance
  • All employees can access the public internet through an exit node in the network. They do not need access to the exit node itself in order to use it
  • The IT team group:it can manage which devices are tagged with tag:application-exit-node
  • The IT team group:it and devices tagged tag:application-exit-node can auto-approve exit nodes
{
  "groups": {
    // Dave is in group:it
    "group:it": ["[email protected]",],
  },
  "acls": [
    // users in group:it can access devices tagged tag:application-exit-node
    { "action": "accept", "src": ["group:it"], "dst": ["tag:application-exit-node:*"] },
    // all employees can use exit nodes
    { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:internet:*"] },
  ],
  "tagOwners": {
    // users in group:it can apply the tag tag:application-exit-node
    "tag:application-exit-node": ["group:it"],
  },
  "autoApprovers": {
    // exit nodes advertised by users in group:it or devices tagged
    // tag:application-exit-node will be automatically approved
    "exitNode": ["tag:application-exit-node", "group:it"],
  }
}

Application peering

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

What this ACL does:

  • Devices tagged tag:database can access other devices tagged tag:database
  • Devices tagged tag:gcp and tag:aws can access devices tagged tag:database, but not vice versa
  • The infrastructure team group:infra can manage which devices are tagged with tag:database, tag:gcp, and tag:aws
{
  "groups": {
    // Carl is in group:infra
    "group:infra": ["[email protected]",],
  },
  "acls": [
    // devices tagged tag:database, tag:gcp, or tag:aws can access devices
    // tagged tag:database
    { "action": "accept", "src": ["tag:database", "tag:gcp","tag:aws"], "dst": ["tag:database:*"] },
  ],
  "tagOwners": {
    // users in group:infra can apply the tag tag:database
    "tag:database": ["group:infra"],
    // users in group:infra can apply the tag tag:gcp
    "tag:gcp": ["group:infra"],
    // users in group:infra can apply the tag tag:aws
    "tag:aws": ["group:infra"],
  },
}

VPC access (VPC peering)

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 node, 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 on your tailnet, disable subnet route masquerading. You can also use auto approvers so that routes are automatically approved.

What this ACL does:

  • Members of the IT team group:it can access the devices tagged tag:vpc-peering, for maintenance
  • Members of the development team group:dev can access devices in the subnets 10.0.0.0/16 and 10.128.0.0/24
  • The subnet 10.0.0.0/16 can access the subnet 10.128.0.0/24 and vice versa, if subnet route masquerading is disabled
  • The IT team group:it can manage which devices are tagged with tag:vpc-peering
  • The IT team group:it and devices tagged tag:vpc-peering can auto-approve routes for 10.0.0.0/16 and 10.128.0.0/24
{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["[email protected]", "[email protected]",],
    // Dave is in group:it
    "group:it": ["[email protected]",],
  },
  "acls": [
    // users in group:it can access devices tagged tag:vpc-peering
    { "action": "accept", "src": ["group:it"], "dst": ["tag:vpc-peering:*"] },
    // users in group:dev, and devices in subnets 10.0.0.0/16 and
    // 10.128.0.0/24 can access devices in subnets 10.0.0.0/16 and
    // 10.128.0.0/24
    { "action": "accept", "src": ["group:dev","10.0.0.0/16", "10.128.0.0/24"], "dst": ["10.0.0.0/16:*", "10.128.0.0/24:*"] },
  ],
  "tagOwners": {
    // users in group:it can apply the tag tag:vpc-peering
    "tag:vpc-peering": ["group:it"],
  },
  "autoApprovers": {
    "routes": {
      // subnets included in 10.0.0.0/16 advertised by devices tagged
      // tag:vpc-peering or users in group:it will be automatically approved
      "10.0.0.0/16": ["tag:vpc-peering", "group:it"],
      // subnets included in 10.128.0.0/24 advertised by devices tagged
      // tag:vpc-peering or users in group:it will be automatically approved
      "10.128.0.0/24": ["tag:vpc-peering", "group:it"],
    },
  },
}

Share access with a contractor

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.

What this ACL does:

  • All employees can access their own devices
  • Members of the development team group:dev can access devices tagged tag:dev, such as package registries and databases
  • Contractors who have accepted a share invite can access devices tagged tag:dev which have been shared with them
{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["[email protected]", "[email protected]",],
  },
  "acls": [
    // all employees can access their own devices
    { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:self:*"] },
    // users in group:dev and contractors who have accepted a share invite can
    // access devices tagged tag:dev
    { "action": "accept", "src": ["group:dev","autogroup:shared"], "dst": ["tag:dev:*"] },
  ],
  "tagOwners": {
    // users in group:dev can apply the tag tag:dev
    "tag:dev": ["group:dev"],
  },
}

Last updated

WireGuard is a registered
trademark of Jason A. Donenfeld.

© 2022 Tailscale Inc.

Privacy & Terms