Grant samples

This article provides example grants for common scenarios. For information about the syntax, refer to the tailnet policy syntax.

Example	Description	Features
Allow all	Provides the default ACL policy that allows all connections between devices in your tailnet. Devices shared from another network can only respond to incoming connections.	grants
Allow users access to their own devices	Enables members of your tailnet to access their own devices. This is a basic access control setup focusing on self-device management.	grants, autogroups
Allow using exit nodes	Permits all members of your tailnet to use any available exit nodes. This configuration enables internet access routing through exit nodes.	grants, autogroups
Allow access to resources based on device posture	Controls access to resources through different routers based on device posture management rules. Engineering team access is granted based on specific device requirements while others use designated office routers.	grants, postures, tags, via
Route traffic through exit nodes based on location	Segments exit node access based on user office location. Allows different user groups to access internet resources through geographically appropriate exit nodes.	grants, groups, tags, via
Route group traffic through app connectors	Segments application access through specific app connectors for different user groups. Users are directed through designated app connectors based on their service needs (GitHub or Salesforce).	grants, groups, tags, via
Customize autogroup:internet	Creates custom internet access rules using IP sets and routes traffic through specific subnet routers based on user groups. Enables location-based routing through office routers for different user groups.	grants, ipsets, groups, tags, via
Allow access to different environments by group	Provides varied access levels to internal tools based on team membership. Implements port-specific access controls for different user groups.	grants, groups, tags
Allow access to different environments using device posture	Controls access to different infrastructure environments based on device posture policies. Routes traffic through specific app connectors based on destination and security requirements.	grants, groups, tags, postures, via
Allow access to Kubernetes operator with privileges	Manages Kubernetes operator access with different privilege levels for production and reader groups. Implements group-based impersonation for administrative and read-only access.	grants, groups, tags, app capabilities
Allow based on purpose using tags	Creates a hierarchical access structure between frontend, backend, and logging devices. Implements purpose-based access control using device tags.	grants, tags
Application peering	Enables connection between applications across cloud providers and SaaS applications. Implements database access controls and infrastructure team management capabilities.	grants, groups, tags, tagOwners
CI/CD development pipeline	Restricts access to deployment pipeline components based on team roles. Separates development, CI/CD, and production environment access with team-based controls.	grants, groups, tags, tagOwners
Allow access to internal VPN	Manages internal application access based on job roles and department membership. Provides role-based access control for different internal resources with IT team oversight.	grants, groups, autogroups, tags, tagOwners
Monitor application access	Enables monitoring server access to services on specific ports across the network. Provides DevOps team control over monitoring and logging infrastructure.	grants, groups, tags, tagOwners
Network microsegmentation	Implements logical network segmentation with support team access across segments. Creates isolated network segments with controlled cross-segment access for support purposes.	grants, groups, tags, tagOwners
Paired programming	Enables remote paired programming sessions through SSH access to shared devices. Provides controlled access for specific users to pair programming environments.	grants, tags, tagOwners
Allow remote access to a protected environment	Implements tiered access control for development and production environments. Separates access levels between developers and DevOps team while maintaining shared access to monitoring tools.	grants, groups, autogroups, tags, tagOwners
Remote development	Facilitates remote development setup with access to development resources and personal devices. Enables developer access to remote workstations and development tools.	grants, groups, autogroups, tags, tagOwners
Share access with a contractor	Manages resource sharing with contractors while maintaining internal development access controls. Implements port-restricted access for shared users to specific development resources.	grants, groups, autogroups, tags, tagOwners
Starter plan example	Provides basic access control with employee self-device access and admin-controlled corporate device access. Separates production and corporate device access with admin-only production control.	grants, autogroups, tags, tagOwners
VPC access	Enables developer access to VPC resources with DevOps team management capabilities. Implements VPC peering and subnet access controls with admin oversight.	grants, groups, autogroups, tags, tagOwners, autoApprovers

Allow all

The following example grant is the equivalent of the default ACL policy and allows all connections between devices in your tailnet.

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

"grants": [
  {
    "src": ["*"],
    "dst": ["*"],
    "ip":  ["*"],
  },
]

Allow users access to their own devices

The following example grant rule allows members of your tailnet to access their own devices.

"grants": [
  {
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "ip":  ["*"],
  },
]

Allow using exit nodes

The following grant rule allows all members of your tailnet to use any available exit nodes.

"grants": [
  {
    "src": ["autogroup:member"],
    "dst": ["autogroup:internet"],
    "ip":  ["*"],
  },
]

Allow access to resources based on device posture

You can use the via field in grants to segment resource access through different routers based on device posture management rules.

The following example demonstrates a scenario in which the engineering team group can access a 192.0.2.0/24 using any available router if they comply with the latestMac posture (which ensures they are running the latest stable version of the Tailscale client for macOS). Anyone else (autogroup:member) can access 192.0.2.0/24 using the designated office router (tag:office-router).

The group and tag assignments are outside the scope of this example.

"postures": {
    "posture:latestMac": [
        "node:os == 'macos'",
        "node:osVersion == '13.4.0'",
        "node:tsReleaseTrack == 'stable'",
    ]
},
"grants": [
    {
        "src": ["group:eng"],
        "srcPosture": ["posture:latestMac"],
        "dst": ["192.0.2.0/24"],
        "ip": ["*"],
    },
    {
        "src": ["autogroup:member"],
        "dst": ["192.0.2.0/24"],
        "via": ["tag:office-router"],
        "ip": ["*"],
    },
]

Route traffic through exit nodes based on location

You can use the via field in grants to segment different exit nodes to different users.

The following example demonstrates a scenario where users can access internet resources through an exit node based on the user's home office location.

Users in the Toronto (group:tor) and Seattle (group:sea) offices can access internet resources using exit nodes near their home offices (or directly from their device when exit nodes are not selected). Users on the engineering team (group:eng) can access internet resources using any exit node in the tailnet (or directly from their device when exit nodes are not selected).

The group and tag assignments are outside the scope of this example.

"grants": [
    {
        "src": ["group:tor"],
        "dst": ["autogroup:internet"],
        "via": ["tag:exit-node-tor"],
        "ip": ["*"],
    },
    {
        "src": ["group:sea"],
        "dst": ["autogroup:internet"],
        "via": ["tag:exit-node-sea"],
        "ip": ["*"],
    },
    {
        "src": ["group:eng"],
        "dst": ["autogroup:internet"],
        "ip": ["*"],
    },
]

Route group traffic through app connectors

You can use the via field in grants to segment different app connectors to different users.

The following example demonstrates a scenario in which users in the group github-users can access GitHub through an app connector tagged github-appconnector while users in the group salesforce-users can access Salesforce through an app connector tagged salesforce-appconnector.

Note: The group and tag assignments are outside the scope of this example.

"grants": [
    {
        "src": ["group:github-users"],
        "dst": ["autogroup:internet"],
        "ip":  ["*"],
        "via": ["tag:github-appconnector"],
    },
    {
        "src": ["group:salesforce-users"],
        "dst": ["autogroup:internet"],
        "ip":  ["*"],
        "via": ["tag:salesforce-appconnector"],
    }
]

Customize `autogroup:internet`

The following example uses IP sets and grants to customize the autogroup:internet target, then routes traffic from users in specific groups through the customized IP set.

It accomplishes this by creating an IP set named internet that includes the autogroup:internet target and excludes the cdn-edge (production application gateways) and partner-net (publicly accessible partner network) IP sets. Then, it creates two grants that route user traffic to the internet IP set through a specific subnet router based on which group they're a member of.

Members of the sea group (users in Seattle) go through the subnet router tagged with officerouter-sea, and members of the lon group (users in London) go through the subnet router tagged with officerouter-lon.

The group and tag assignments are outside the scope of this example.

"ipsets": {
  "ipset:internet": [
    "add autogroup:internet",
    "remove ipset:cdn-edge",
    "remove ipset:partner-net"
  ],
    "ipset:cdn-edge": ["198.51.100.6", "198.51.100.7", "198.51.100.13", "198.51.100.14"],
    "ipset:partner-net": ["203.0.113.0/24"]
  }
  "grants": [
  {
    "src": ["group:sea"],
    "dst": ["ipset:internet"],
    "ip":  ["*"],
    "via": ["tag:officerouter-sea"],
  },
  {
    "src": ["group:lon"],
    "dst": ["ipset:internet"],
    "ip":  ["*"],
    "via": ["tag:officerouter-lon"],
  }
]

Allow access to different environments by group

The following example grants the engineering team access to devices tagged with internal-tools through any port number, the sales team access to devices tagged with internal-tools on TCP ports 443 or 22, and everyone else access to devices tagged with dns through port 53.

"grants": [
  {
    "src": ["group:eng"],
    "dst": ["tag:internal-tools"],
    "ip":  ["*"],
  },
  {
    "src": ["group:sales"],
    "dst": ["tag:internal-tools"],
    "ip":  ["tcp:443", "tcp:22"],
  },
  {
    "src": ["*"],
    "dst": ["tag:dns"],
    "ip":  ["udp:53"],
  }
]

Allow access to different environments using device posture

The following examples use several grants to direct traffic from the devs group through different app connectors depending on the destination IP set and device posture policies.

Traffic from the devs group to the prod-infra IP set must meet the strict-mac device policy and go through the app connector tagged prod-connector.
Traffic from the devs group to the stg-infra IP set must meet the semi-strict-mac device policy and go through the app connector tagged stg-connector.
All other traffic from the devs group goes through the app connector tagged dev-connector.

The group, IP set, posture, and tag assignments are outside the scope of this example.

"grants": [
  {
    "src": ["group:devs"],
    "dst": ["ipset:prod-infra"],
    "ip":  ["*"],
    "via": ["tag:prod-connector"],
    "srcPosture": ["posture:strict-mac"]
  },
  {
    "src": ["group:devs"],
    "dst": ["ipset:stg-infra"],
    "ip":  ["*"],
    "via": ["tag:stg-connector"],
    "srcPosture": ["posture:semi-strict-mac"]

  },
  {
    "src": ["group:devs"],
    "dst": ["ipset:dev-infra"],
    "ip":  ["*"],
    "via": ["tag:dev-connector"],
    "srcPosture": ["posture:any-mac"]
  },
]

Allow access to Kubernetes operator with privileges

The following example grant allows members of the production team (group:prod) access to devices running the Kubernetes operator and allows them to impersonate the system:masters group (which has admin privileges). It also allows members of the k8s-readers group access to devices running the Kubernetes operator and allows them to impersonate the tailnet-readers group (which has read-only privileges).

Note: The group and tag assignments are outside the scope of this example.

{
  "grants": [
    {
      "src": [
        "group:prod"
      ],
      "dst": [
        "tag:k8s-operator"
      ],
      "app": {
        "tailscale.com/cap/kubernetes": [
          {
            "impersonate": {
              "groups": [
                "system:masters"
              ]
            }
          }
        ]
      }
    },
    {
      "src": [
        "group:k8s-readers"
      ],
      "dst": [
        "tag:k8s-operator"
      ],
      "app": {
        "tailscale.com/cap/kubernetes": [
          {
            "impersonate": {
              "groups": [
                "tailnet-readers"
              ]
            }
          }
        ]
      }
    }
  ]
}

Allow based on purpose using tags

The following example uses tags to grant frontend devices (tag:frontend) access to backend devices (tag:backend) and backend devices (tag:backend) access to logging devices (tag:logging).

{
  "grants": [
    {
      "src": ["tag:frontend"],
      "dst": ["tag:backend"],
      "ip": ["*"]
    },
    {
      "src": ["tag:backend"],
      "dst": ["tag:logging"],
      "ip": ["*"]
    }
  ]
}

Application peering

Infrastructure teams can use Tailscale to connect applications or services in multiple cloud providers or SaaS applications. In this scenario, one application can connect with another application in your network, for example, to stream data from one database to another, such as with Materialize.

What this example does:

Devices tagged with tag:database can access other devices tagged with tag:database.
Devices tagged with tag:gcp and tag:aws can access devices tagged with 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": ["carl@example.com",],
  },
  "grants": [
    // Devices tagged with tag:database, tag:gcp, or tag:aws can access devices
    // tagged with tag:database
    {
        "src": ["tag:database", "tag:gcp","tag:aws"],
        "dst": ["tag:database"],
        "ip": ["*"]
    },
  ],
  "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"],
  },
}

CI/CD development pipeline

DevOps and SRE teams 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 example does:

Members of the development team group:dev can access the devices tagged with tag:dev (such as code repositories and license servers).
Members of the DevOps team group:devops can access the devices tagged with 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 with tag:prod and tag:dev (to apply tags as part of the deployment pipeline).

{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["alice@example.com", "bob@example.com",],
    // Carl is in group:devops
    "group:devops": ["carl@example.com",],
  },
  "grants": [
    // Users in group:dev can access devices tagged with tag:dev
    {
        "src": ["group:dev"],
        "dst": ["tag:dev"],
        "ip":  ["*"]
    },
    // Users in group:devops can access devices tagged with tag:ci or
    // tagged eith tag:prod
    {
        "src": ["group:devops"],
        "dst": ["tag:ci", "tag:prod"],
        "ip":  ["*"]
    },
  ],
  "tagOwners": {
    // Users in group:devops can apply the tag tag:ci
    "tag:ci": ["group:devops"],
    // Users in group:devops or devices tagged with tag:ci can apply the tag tag:dev
    "tag:dev": ["group:devops", "tag:ci"],
    // Users in group:devops or devices tagged with tag:ci can apply the tag tag:prod
    "tag:prod": ["group:devops", "tag:ci"],
  },
}

Allow access to internal VPN

You can use Tailscale to allow users to access internal applications, including custom 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.

What this example does:

Members of the engineering team group:engineering can access the devices tagged with tag:engineering.
Members of the finance team group:finance can access the devices tagged with tag:finance.
Members of the legal team group:legal can access the devices tagged with tag:legal.
All employees can access the devices tagged with tag:internal.
All Tailscale Admins (autogroup:admin) (such as the IT team) can manage which devices are tagged with tag:engineering, tag:finance, tag:legal, and tag:internal.

{
  "groups": {
    // Alice is in group:engineering
    "group:engineering": ["alice@example.com",],
    // Bob is in group:finance
    "group:finance": ["bob@example.com",],
    // Carl is in group:legal
    "group:legal": ["carl@example.com",],
    // Dave has the admin role in Tailscale, so in autogroup:admin
  },
  "grant": [
    // Users in group:engineering can access devices tagged with tag:engineering
    {
        "src": ["group:engineering"],
        "dst": ["tag:engineering"],
        "ip": ["*"]
    },
    // Users in group:finance can access devices tagged with tag:finance
    {
        "src": ["group:finance"],
        "dst": ["tag:finance"],
        "ip": ["*"]
    },
    // Users in group:legal can access devices tagged with tag:legal
    {
        "src": ["group:legal"],
        "dst": ["tag:legal"],
        "ip": ["*"]
    },
    // All employees can access devices tagged with tag:internal
    {
        "src": ["autogroup:member"],
        "dst": ["tag:internal"],
        "ip": ["*"]
    },
  ],
  "tagOwners": {
    // Users who are Tailscale admins can apply the tag tag:engineering
    "tag:engineering": ["autogroup:admin"],
    // Users who are Tailscale admins can apply the tag tag:finance
    "tag:finance": ["autogroup:admin"],
    // Users who are Tailscale admins can apply the tag tag:legal
    "tag:legal": ["autogroup:admin"],
    // Users who are Tailscale admins can apply the tag tag:internal
    "tag:internal": ["autogroup:admin"],
  },
}

Monitor application access

DevOps or SRE teams 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.

What this example does:

Devices tagged with tag:monitoring can access services on ports 80, 443, 9100.
Devices tagged with 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": ["carl@example.com",],
  },
  "grants": [
    // Devices tagged with tag:monitoring can access all devices in the network on
    // ports 80, 443, and 9100, and devices tagged with tag:logging on all ports
    {
        "src": ["tag:monitoring"],
        "dst": ["tag:logging"],
        "ip": ["80", "443", "9100"] // Implies TCP, UDP, and ICMP
    },
    // Users in group:devops can access devices tagged with tag:monitoring and
    // tag:logging
    {
        "src": ["group:devops"],
        "dst": ["tag:monitoring", "tag:logging"],
        "ip": ["*"]
    },
  ],
  "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"],
  },
}

Network microsegmentation

Network 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. Sometimes, you might still need a support team or tagged devices to access all segments.

What this example does:

Members of the support team group:support can access devices tagged tag:segment-abc and tag:segment-xyz on port 443.
Devices tagged with tag:support can access devices tagged tag:segment-abc and tag:segment-xyz on port 443.

{
  "grants": [
    // allow group:support access to all segments on port 443
    {
        "src": ["group:support"],
        "dst": ["tag:segment-abc", "tag:segment-xyz"],
        "ip": ["443"]
    },
    // allow tag:support access to all segments on port 443
    {
        "src": ["tag:support"],
        "dst": ["tag:segment-abc", "tag:segment-xyz"],
        "ip": ["443"]
    },
  ],
  "groups": {
    "group:support": ["alice@example.com", "bob@example.com"],
  },
  "tagOwners": {
    "tag:support": ["autogroup:admin"],
   },
}

Paired programming

You can use Tailscale for remotely paired programming sessions on the same device. 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:

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.

{
  "grants": [
    // Alice and Bob can access devices tagged with tag:pair-programming on
    // port 22
    {
        "src": ["alice@example.com", "bob@example.com"],
        "dst": ["tag:pair-programming"],
        "ip": ["22"]
    },
  ],
  "tagOwners": {
     // Bob can apply the tag tag:pair-programming
    "tag:pair-programming": ["bob@example.com"],
  },
}

Allow remote access to a protected environment

DevOps, infrastructure, and SRE teams 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 have access to resources in a development environment. All developers can access monitoring tools, such as Grafana.

What this example does:

All employees can access their own devices (such as remote workstations).
Members of the development team group:dev can access the devices tagged with tag:dev (such as license servers).
All Tailscale Admins (autogroup:admin) (such as members of the DevOps team) can access the devices tagged with tag:prod (such as the production environment).
All employees can access devices tagged with tag:monitoring on ports 80 and 443 (such as monitoring dashboards).
All Tailscale Admins (autogroup:admin) can manage which devices are tagged with tag:dev, tag:prod, and tag:monitoring.

{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["alice@example.com", "bob@example.com",],
    // Carl has the admin role in Tailscale, so in autogroup:admin
  },
  "grants": [
    // All employees can access their own devices
    {
        "src": ["autogroup:member"],
        "dst": ["autogroup:self:*"],
        "ip": ["*"]
    },
    // Users in group:dev can access devices tagged with tag:dev
    {
        "src": ["group:dev"],
        "dst": ["tag:dev:*"],
        "ip": ["*"]
    },
    // Users who are Tailscale admins can access devices tagged with tag:prod
    {
        "src": ["autogroup:admin"],
        "dst": ["tag:prod:*"],
        "ip": ["*"]
    },
     // All employees can access devices tagged with tag:monitoring on
     // ports 80 and 443
    {
        "src": ["autogroup:member"],
        "dst": ["tag:monitoring"],
        "ip": ["80", "443"]
    },
  ],
  "tagOwners": {
     // Users who are Tailscale admins can apply the tag tag:monitoring
    "tag:monitoring": ["autogroup:admin"],
    // Users who are Tailscale admins can apply the tag tag:dev
    "tag:dev": ["autogroup:admin"],
    // Users who are Tailscale admins can apply the tag tag:prod
    "tag:prod": ["autogroup:admin"],
  },
}

Remote development

Development teams 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 another device in their network. This is useful for accessing a workstation with more processing power, such as machine learning or building. You might also use a remote code environment like GitHub Codespaces, Gitpod, or Coder. You might access a license server, a package registry, a production database, or another development or build resource from your development environment. You might also access a self-hosted or private code repository.

What this example does:

All employees can access their own devices.
Members of the development team group:dev can access devices tagged with 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": ["alice@example.com", "bob@example.com",],
  },
  "grants": [
     // All employees can access their own devices
    {
        "src": ["autogroup:member"],
        "dst": ["autogroup:self:*"],
        "ip": ["*"]
    },
    // Users in group:dev can access devices tagged with tag:dev
    {
        "src": ["group:dev"],
        "dst": ["tag:dev:*"],
        "ip": ["*"]
    },
  ],
  "tagOwners": {
    // Users in group:dev can apply the tag tag:dev
    "tag:dev": ["group:dev"],
  },
}

Your development team can use Tailscale to share access to specific resources with a contractor, such as a database or a hosted code repository. In this scenario, developers can access internal development resources, and specific devices can be shared with a contractor.

What this example does:

All employees can access their own devices.
Members of the development team group:dev can access devices tagged with tag:dev (such as package registries and databases)
Contractors who have accepted a share invite can access devices tagged with tag:dev (that have been shared with them).

{
  "groups": {
    // Alice and Bob are in group:dev
    "group:dev": ["alice@example.com", "bob@example.com",],
  },
  "grants": [
    // All employees can access their own devices
    {
        "src": ["autogroup:member"],
        "dst": ["autogroup:self:*"],
        "ip": ["*"]
    },
    // Users in group:dev and contractors who have accepted a share invite can
    // access devices tagged with tag:dev using TCP ports 80 through 443.
    {
        "src": ["group:dev","autogroup:shared"],
        "dst": ["tag:dev:*"],
        "ip": ["tcp:80-443"]
    },
  ],
  "tagOwners": {
    // Users in group:dev can apply the tag tag:dev
    "tag:dev": ["group:dev"],
  },
}

Starter plan example

The following example demonstrates a basic starter policy file where all users can access their remote devices and any tagged corporate devices, such as servers. 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.

What this example does:

All employees can access their own devices.
All employees can access corporate devices tagged with tag:corp.
All Tailscale Admins (autogroup:admin) can access devices tagged with tag:prod.
All Tailscale Admins can manage which devices are tagged with tag:corp and tag:prod.

{
   "grants": [
    // All employees can access their own devices
    {
        "src": ["autogroup:member"],
        "dst": ["autogroup:self"],
        "ip": ["*"]
    },
    // All employees can access devices tagged with tag:corp
    {
        "src": ["autogroup:member"],
        "dst": ["tag:corp"],
        "ip": ["*"]
    },
    // All Tailscale admins can access devices tagged with tag:prod
    {
        "src": ["autogroup:admin"],
        "dst": ["tag:prod"],
        "ip": ["*"]
    },
   ],
  "tagOwners": {
    // All Tailscale admins can manage which devices are tagged tag:corp and tag:prod
    "tag:corp": ["autogroup:admin"],
    "tag:prod": ["autogroup:admin"],
   },
 }

VPC access

You 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 the following example, developers can access resources in the VPC, the DevOps team can manage access to the VPC, and VPCs can peer to each other if they don't have overlapping IP ranges.

What this example does:

Admins (autogroup:admin) can access the devices tagged with tag:vpc-peering for maintenance.
The development team (group:dev) can access devices in the subnets 192.0.2.0/24 and 198.51.100.0/24.
The subnet 192.0.2.0/24 can access the subnet 198.51.100.0/24 and vice versa (if subnet route masquerading is disabled).
Admins (autogroup:admin) can manage which devices are tagged with tag:vpc-peering.
Admins (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.

{
  "groups": {
    "group:dev": ["alice@example.com", "bob@example.com",],
  },
  "grants": [
    {
        "src": ["autogroup:admin"],
        "dst": ["tag:vpc-peering:*"],
        "ip": ["*"]
    },
    {
        "src": ["group:dev","192.0.2.0/24", "198.51.100.0/24"],
        "dst": ["192.0.2.0/24:*", "198.51.100.0/24:*"],
        "ip": ["*"]
    },
  ],
  "tagOwners": {
    "tag:vpc-peering": ["autogroup:admin"],
  },
  "autoApprovers": {
    "routes": {
      "192.0.2.0/24": ["tag:vpc-peering", "autogroup:admin"],
      "198.51.100.0/24": ["tag:vpc-peering", "autogroup:admin"],
    },
  },
}

You can use a subnet router to connect an existing subnet to your tailnet without installing Tailscale on every device:

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 to automatically approve routes.