ACL and access rule samples
This article provides example access controls (ACLs) for common scenarios. For information about the syntax, refer to the tailnet policy syntax.
Example | Description | Uses |
---|---|---|
Allow all | The default tailnet policy that allows all devices within the tailnet to access other devices in the tailnet. | ACLs, SSH |
Resource-level access policies | Allow specific devices to access specific resources within the tailnet. | ACLs, hosts |
Restrict based on purpose (tags) | Allow specific devices to access specific resources within the tailnet using tags. | ACLs |
Restrict based on group | Manage access to resources using autogroups, custom groups, and provisioned groups. | ACLs, groups |
Restrict based on individual users | Manage access to resources for specific users. | ACLs |
Starter plan ACL | Let employees access their own devices and devices tagged with corp and let admins access devices tagged with corp or prod . | ACLs, tag owners |
Application allowlisting for third-party SaaS apps | Allow traffic to a specific application through a designated exit node. | ACLs, autogroups, tags, tag owners, auto approvers |
Access to an internal application (VPN) | Manage user access applications based on their job role. | ACLs, groups, tag owners |
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 |
Remote access to a production environment | Manage user access to the production environment based on their job role. | ACLs, groups, tag owners, tests |
VPC access (VPC peering) | Manage access to a virtual private cloud using access control lists. | ACLs, groups, tag owners, auto approvers |
Share access with a contractor | Allow a third-party contractor to access shared resources in the development environment. | ACLs, groups, tag owners |
Remote development | Manage access to a remote development environment. | ACLs, groups, tag owners |
Pair programming | Create a paired programming environment multiple engineers can connect to using SSH. | ACLs, tag owners |
CI/CD deployment pipeline | Manage access to resources based on job roles. | ACLs, groups, tag owners |
Monitoring access to applications | Allow a monitoring server to access all applications on common ports. | ACLs, groups, tag owners |
Application peering | Allow multiple cloud providers or applications to access each other. | ACLs, groups, tag owners |
Allow all (default ACL)
When you first create your Tailscale network (called 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.
What this ACL does:
- All devices on the tailnet can access all other devices on the tailnet.
- All users can establish a Tailscale SSH session to their own devices using check mode, as either root or non-root.
- If you have a subnet router initialized with
--snat-subnet-routes=false --stateful-filtering=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 tailnet, that device cannot access any devices on the tailnet. The device can only respond to incoming connections from the tailnet.
{
"acls": [
// Allow all connections.
{ "action": "accept", "src": ["*"], "dst": ["*:*"] },
],
"ssh": [
// Allow all users to SSH into their own devices in check mode.
{
"action": "check",
"src": ["autogroup:member"],
"dst": ["autogroup:self"],
"users": ["autogroup:nonroot", "root"]
}
]
}
In 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 replacing autogroup: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.
Resource-level access policies
This example is possible with all plans.
You 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 ACL does:
- The device with the IP address
100.3.4.5
can access the device with the IP address100.101.102.103
. - The device with the IP address
100.3.4.5
can access devices in the subnet10.0.0.0/16
through a subnet router. - The device with the hostname
example-host-1
can access devices in the subnet10.0.0.0/16
. - The device with the hostname
example-host-1
can access the device with the hostnameexample-network-1
.
{
"acls": [
// 100.3.4.5 can access 100.101.102.103
{ "action": "accept", "src": ["100.3.4.5"], "dst": ["100.101.102.103:*"] },
// 100.3.4.5 can access devices in the subnet 10.0.0.0/16
{ "action": "accept", "src": ["100.3.4.5"], "dst": ["10.0.0.0/16:*"] },
// Named host example-host-1 can access devices in the subnet 10.0.0.0/16
{ "action": "accept", "src": ["example-host-1"], "dst": ["10.0.0.0/16:*"] },
// Named host example-host-1 can access named host example-network-1
{ "action": "accept", "src": ["example-host-1"], "dst": ["example-network-1:*"] },
],
// Readable shorthands for devices and networks.
"hosts": {
"example-host-1": "100.101.102.103",
"example-network-1": "10.0.0.0/24",
},
}
Restrict based on purpose (tags)
This example is possible with all plans.
Tags 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.
What this ACL does:
- Devices tagged with
tag:frontend
can access devices tagged withtag:backend
. - Devices tagged with
tag:backend
can access devices tagged withtag:logging
.
{
"acls": [
// Devices tagged with tag:frontend can access devices tagged with tag:backend
{ "action": "accept", "src": ["tag:frontend"], "dst": ["tag:backend:*"] }
// Devices tagged with tag:backend can access devices tagged with tag:logging
{ "action": "accept", "src": ["tag:backend"], "dst": ["tag:logging:*"] },
],
}
Restrict based on group
You can enable access to resources on your tailnet with autogroups, custom groups, or groups provisioned from supported identity providers.
With autogroups
This example is possible with all plans.
Autogroups are built-in groups that automatically include users, destinations, or usernames with the same properties.
What this ACL does:
- All tailnet members
autogroup:member
can access devices tagged withtag:frontend
. - All Tailscale Admins (
autogroup:admin
) can access devices tagged withtag:backend
ortag:logging
.
{
"acls": [
// All tailnet members can access devices tagged with tag:fontend
{ "action": "accept", "src": ["autogroup:member"], "dst": ["tag:frontend:*"] }
// All Tailscale admins can access devices tagged with tag:prod
{ "action": "accept", "src": ["autogroup:admin"], "dst": ["tag:backend:*", "tag:logging:*"] },
],
}
With custom groups
This example is possible with the Personal, Premium, and Enterprise plans.
Custom 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.
What this ACL does:
- The Engineering team
group:engineering
consists ofalice@example.com
andbob@example.com
. - The DevOps team
group:engineering
consists ofamelie@example.com
andcarl@example.com
. - The Engineering team
group:engineering
can access devices tagged withtag:frontend
ortag:backend
. - The DevOps team
group:devops
can access devices tagged withtag:frontend
,tag:backend
, ortag:logging
.
{
"groups": {
// Alice and Bob are in group:engineering
"group:engineering": ["alice@example.com", "bob@example.com"],
// Amelie and Carl are in group:devops
"group:devops": ["amelie@example.com", "carl@example.com"],
},
"acls": [
// Users in group:engineering can access devices tagged with tag:frontend or tag:backend
{ "action": "accept", "src": ["group:engineering"], "dst": ["tag:frontend:*", "tag:backend:*"] },
// Users in group:devops can access devices tagged with tag:frontend or tag:backend or tag:logging
{ "action": "accept", "src": ["group:devops"], "dst": ["tag:frontend:*", "tag:backend:*", "tag:logging:*"] },
],
}
With provisioned groups
You can use group provisioning from supported identity providers and avoid maintaining custom groups in your ACLs.
{
"acls": [
// Users in group:engineering@example.com can access devices tagged with tag:frontend or tag:backend
{ "action": "accept", "src": ["group:engineering@example.com"], "dst": ["tag:frontend:*", "tag:backend:*"] },
// Users in group:devops@example.com can access devices tagged with tag:frontend or tag:backend or tag:logging
{ "action": "accept", "src": ["group:devops@example.com"], "dst": ["tag:frontend:*", "tag:backend:*", "tag:logging:*"] },
],
}
Restrict based on individual user
This example is possible with the Personal, Premium, and Enterprise plans.
You can enable access to resources based on individual users.
What this ACL does:
- User Alice can access devices tagged with
tag:frontend
. - User Bob can access devices tagged with
tag:backend
.
{
"acls": [
// Alice can access devices tagged with tag:frontend
{ "action": "accept", "src": ["amelie@example.com"], "dst": ["tag:frontend:*"] },
// Bob can access devices tagged with tag:backend
{ "action": "accept", "src": ["bob@example.com"], "dst": ["tag:backend:*"] },
]
}
Starter plan ACL
This example provides remote access to corp and prod devices. It is suitable for many Starter plan use cases and is possible with all plans.
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. 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 ACL 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 withtag:prod
. - All Tailscale Admins can manage which devices are tagged with
tag:corp
andtag:prod
.
{
"acls": [
// All employees can access their own devices
{ "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] },
// All employees can access devices tagged with tag:corp
{ "action": "accept", "src": ["autogroup:member"], "dst": ["tag:corp:*"] },
// All Tailscale admins can access devices tagged with tag:prod
{ "action": "accept", "src": ["autogroup:admin"], "dst": ["tag:prod:*"] },
],
"tagOwners": {
// All Tailscale admins can manage which devices are tagged tag:corp and tag:prod
"tag:corp": ["autogroup:admin"],
"tag:prod": ["autogroup:admin"],
},
}
Application allowlisting for third-party SaaS application (IP allowlisting)
This example is possible with all plans.
You 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 to automatically approve exit nodes.
What this ACL does:
- All Tailscale Admins (
autogroup:admin
) (such as the IT team) can access the devices tagged withtag: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 to use it.
- All Tailscale Admins (
autogroup:admin
) (such as the IT team) can manage which devices are tagged withtag:application-exit-node
. - All Tailscale Admins (
autogroup:admin
) and devices tagged withtag:application-exit-node
can auto-approve exit nodes.
{
"groups": {
// Dave has the admin role in Tailscale, so in autogroup:admin
},
"acls": [
// Users who are Tailscale admins can access devices tagged with tag:application-exit-node
{ "action": "accept", "src": ["autogroup:admin"], "dst": ["tag:application-exit-node:*"] },
// All employees can use exit nodes
{ "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"] },
],
"tagOwners": {
// Users who are Tailscale admins can apply the tag tag:application-exit-node
"tag:application-exit-node": ["autogroup:admin"],
},
"autoApprovers": {
// Exit nodes advertised by users who are Tailscale admins or devices tagged
// with tag:application-exit-node will be automatically approved
"exitNode": ["tag:application-exit-node", "autogroup:admin"],
}
}
Access to an internal application (VPN)
This example is possible with the Personal, Premium, and Enterprise plans.
You 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.
What this ACL does:
- Members of the engineering team
group:engineering
can access the devices tagged withtag:engineering
. - Members of the finance team
group:finance
can access the devices tagged withtag:finance
. - Members of the legal team
group:legal
can access the devices tagged withtag: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 withtag:engineering
,tag:finance
,tag:legal
, andtag: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
},
"acls": [
// Users in group:engineering can access devices tagged with tag:engineering
{ "action": "accept", "src": ["group:engineering"], "dst": ["tag:engineering:*"] },
// Users in group:finance can access devices tagged with tag:finance
{ "action": "accept", "src": ["group:finance"], "dst": ["tag:finance:*"] },
// Users in group:legal can access devices tagged with tag:legal
{ "action": "accept", "src": ["group:legal"], "dst": ["tag:legal:*"] },
// All employees can access devices tagged with tag:internal
{ "action": "accept", "src": ["autogroup:member"], "dst": ["tag:internal:*"] },
],
"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"],
},
}
Access to an internal application (VPN) with synced groups
This example is possible with the Enterprise plan.
You 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 ACL does:
- Members of the engineering team in the synced group
group:engineering@example.com
can access the devices tagged withtag:engineering
. - Members of the finance team in the synced group
group:finance team@example.com
can access the devices tagged withtag:finance
. - Members of the legal team in the synced group
group:Legal@example.com
can access the devices tagged withtag: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 withtag:engineering
,tag:finance
,tag:legal
, andtag:internal
.
{
"groups": {
// Alice is in group:engineering@example.com, synced with user & group provisioning
// Bob is in group:finance team@example.com, synced with user & group provisioning
// Carl is in group:Legal@example.com, synced with user & group provisioning
// Dave has the admin role in Tailscale, so in autogroup:admin
},
"acls": [
// Users in synced group:engineering@example.com can access devices tagged with tag:engineering
{ "action": "accept", "src": ["group:engineering@example.com"], "dst": ["tag:engineering:*"] },
// Users in synced group:finance team@example.com can access devices tagged with tag:finance
{ "action": "accept", "src": ["group:finance team@example.com"], "dst": ["tag:finance:*"] },
// Users in synced group:Legal@example.com can access devices tagged with tag:legal
{ "action": "accept", "src": ["group:legal@example.com"], "dst": ["tag:legal:*"] },
// All employees can access devices tagged with tag:internal
{ "action": "accept", "src": ["autogroup:member"], "dst": ["tag:internal:*"] },
],
"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"],
},
}
Remote access to production environment
This example is possible with the Personal, Premium, and Enterprise plans. If only your dev team is using Tailscale, use autogroup:member
instead of group:dev
to use this example on the Starter plan.
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 withtag:dev
(such as license servers). - All Tailscale Admins (
autogroup:admin
) (such as members of the DevOps team) can access the devices tagged withtag:prod
(such as the production environment). - All employees can access devices tagged with
tag:monitoring
on ports80
and443
(such as monitoring dashboards). - All Tailscale Admins (
autogroup:admin
) can manage which devices are tagged withtag:dev
,tag:prod
, andtag:monitoring
- Tests ensure that if ACLs change:
- Carl will still be able to access devices tagged with
tag:prod
on port80
. - Alice will atill be able to access devices tagged with
tag:dev
(but not devices tagged withtag:prod
) on port80
.
- Carl will still be able to access devices tagged with
{
"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
},
"acls": [
// All employees can access their own devices
{ "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] },
// Users in group:dev can access devices tagged with tag:dev
{ "action": "accept", "src": ["group:dev"], "dst": ["tag:dev:*"] },
// Users who are Tailscale admins can access devices tagged with tag:prod
{ "action": "accept", "src": ["autogroup:admin"], "dst": ["tag:prod:*"] },
// All employees can access devices tagged with tag:monitoring on
// ports 80 and 443
{ "action": "accept", "src": ["autogroup:member"], "dst": ["tag:monitoring: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"],
},
"tests": [
{
"src": "carl@example.com",
// Test that Carl can access devices tagged with tag:prod on port 80
"accept": ["tag:prod:80"],
},
{
"src": "alice@example.com",
// Test that Alice can access devices tagged with tag:dev on port 80
"accept": ["tag:dev:80"],
// Test that Alice cannot access devices tagged with tag:prod on port 80
"deny": ["tag:prod:80"],
},
],
}
VPC access (VPC peering)
This example is possible with the Personal, Premium, and Enterprise plans. If only your dev team is using Tailscale, use autogroup:member
instead of group:dev
to use this example on the Starter plan.
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 to automatically approve routes.
What this ACL does:
- All Tailscale Admins (
autogroup:admin
) (such as the IT team) can access the devices tagged withtag:vpc-peering
(for maintenance). - Members of the development team
group:dev
can access devices in the subnets10.0.0.0/16
and10.128.0.0/24
. - The subnet
10.0.0.0/16
can access the subnet10.128.0.0/24
and vice versa (if subnet route masquerading is disabled). - All Tailscale Admins (
autogroup:admin
) (such as the IT team) can manage which devices are tagged withtag:vpc-peering
. - All Tailscale Admins (
autogroup:admin
) and devices tagged withtag:vpc-peering
can auto-approve routes for10.0.0.0/16
and10.128.0.0/24
.
{
"groups": {
// Alice and Bob are in group:dev
"group:dev": ["alice@example.com", "bob@example.com",],
// Dave has the admin role in Tailscale, so in autogroup:admin
},
"acls": [
// Users who are Tailscale admins can access devices tagged with tag:vpc-peering
{ "action": "accept", "src": ["autogroup:admin"], "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 who are Tailscale admins can apply the tag tag:vpc-peering
"tag:vpc-peering": ["autogroup:admin"],
},
"autoApprovers": {
"routes": {
// Subnets included in 10.0.0.0/16 advertised by devices tagged
// with tag:vpc-peering or users who are Tailscale admins will be automatically approved
"10.0.0.0/16": ["tag:vpc-peering", "autogroup:admin"],
// Subnets included in 10.128.0.0/24 advertised by devices tagged with
// tag:vpc-peering or users who are Tailscale admins will be automatically approved
"10.128.0.0/24": ["tag:vpc-peering", "autogroup:admin"],
},
},
}
Share access with a contractor
This example is possible with the Personal, Premium, and Enterprise plans. If only your dev team is using Tailscale, use autogroup:member
instead of group:dev
to use this example on the Starter plan.
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 withtag: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",],
},
"acls": [
// All employees can access their own devices
{ "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] },
// Users in group:dev and contractors who have accepted a share invite can
// access devices tagged with 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"],
},
}
Remote development
This example is possible with the Personal, Premium, and Enterprise plans. If only your dev team is using Tailscale, use autogroup:member
instead of group:dev
to use this example on the Starter plan.
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 withtag:dev
(such as package registries and databases). - The development team
group:dev
can manage which devices are tagged withtag:dev
.
{
"groups": {
// Alice and Bob are in group:dev
"group:dev": ["alice@example.com", "bob@example.com",],
},
"acls": [
// All employees can access their own devices
{ "action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self:*"] },
// Users in group:dev can access devices tagged with 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"],
},
}
Pair programming
This example is possible with the Personal, Premium, and Enterprise plans. If only Alice and Bob are using Tailscale, use autogroup:member
and autogroup:admin
instead of named users to use this example on the Starter plan.
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 ACL does:
- Users Alice and Bob can access the corporate device tagged
tag:pair-programming
on port22
(for SSH). - Bob can manage which devices are tagged
tag:pair-programming
.
{
"acls": [
// Alice and Bob can access devices tagged with tag:pair-programming on
// port 22
{ "action": "accept", "src": ["alice@example.com", "bob@example.com"], "dst": ["tag:pair-programming:22"] },
],
"tagOwners": {
// Bob can apply the tag tag:pair-programming
"tag:pair-programming": ["bob@example.com"],
},
}
CI/CD deployment pipeline
This example is possible with the Personal, Premium, and Enterprise plans.
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 withtag:dev
(such as code repositories and license servers). - Members of the DevOps team
group:devops
can access the devices tagged withtag:ci
(such as the build tooling) andtag:prod
(such as the production environment). - The DevOps team
group:devops
can manage which devices are tagged withtag:dev
,tag:ci
, andtag:prod
. - The tag
tag:ci
can manage which device are tagged withtag:prod
andtag: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",],
},
"acls": [
// Users in group:dev can access devices tagged with tag:dev
{ "action": "accept", "src": ["group:dev"], "dst": ["tag:dev:*"] },
// Users in group:devops can access devices tagged with tag:ci or
// tagged eith 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 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"],
},
}
Monitoring access to applications
This example is possible with the Personal, Premium, and Enterprise plans. If only your DevOps team is using Tailscale, use autogroup:member
instead of group:devops
to use this example on the Starter plan.
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.
What this ACL does:
- Devices tagged with
tag:monitoring
can access services on ports80
,443
,9100
. - Devices tagged with
tag:monitoring
can access services taggedtag:logging
. - The DevOps team
group:devops
can access devices tagged withtag:monitoring
andtag:logging
. - The DevOps team
group:devops
can manage which devices are tagged withtag:monitoring
andtag:logging
.
{
"groups": {
// Carl is in group:devops
"group:devops": ["carl@example.com",],
},
"acls": [
// 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
{ "action": "accept", "src": ["tag:monitoring"], "dst": ["*:80,443,9100", "tag:logging:*"] },
// Users in group:devops can access devices tagged with 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"],
},
}
Application peering
This example is possible with the Personal, Premium, and Enterprise plans. If only your infrastructure team is using Tailscale, use autogroup:member
instead of group:infra
to use this example on the Starter plan.
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 with
tag:database
can access other devices tagged withtag:database
. - Devices tagged with
tag:gcp
andtag:aws
can access devices tagged withtag:database
, but not vice versa. - The infrastructure team
group:infra
can manage which devices are tagged withtag:database
,tag:gcp
, andtag:aws
.
{
"groups": {
// Carl is in group:infra
"group:infra": ["carl@example.com",],
},
"acls": [
// Devices tagged with tag:database, tag:gcp, or tag:aws can access devices
// tagged with 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"],
},
}