Tailscale's Access Control Lists (ACLs) are a powerful feature for securing your network. They allow fine-grained control over which users and devices can access specific resources. To give you a better understanding of how to implement advanced access controls, let's walk through some practical examples.

Scenario 1: Role-Based Access to Servers

Imagine you have two groups of machines in your network: development servers and production servers. You want your developers to access the development servers but not the production ones.

Defining Groups and Tags

First, you'll need to create groups for your users and tags for your devices.

"Groups": {
  "group:developers": ["alice@example.com", "bob@example.com"],
  "group:admins": ["admin@example.com"]
},
"Tags": {
  "tag:dev-server": ["100.100.100.1", "100.100.100.2"],
  "tag:prod-server": ["100.100.200.1", "100.100.200.2"]
}

ACL Rules

Next, define ACL rules to grant access to the developers.

"ACLs": [
  {
    "Action": "accept",
    "Users": ["group:developers"],
    "Ports": ["tag:dev-server:*"]
  },
  {
    "Action": "accept",
    "Users": ["group:admins"],
    "Ports": ["*:*"]
  }
],

In this example, developers can access any port on the development servers, while admins have unrestricted access.

Scenario 2: Restricting Access to Sensitive Services

Now, let's say you have a financial service running on port 8443 that should only be accessible to the finance team.

Defining Groups

Add your finance team members to a group.

"Groups": {
  "group:finance": ["carol@example.com", "dave@example.com"]
},

ACL Rules

Create a rule that specifies access to the financial service.

"ACLs": [
  {
    "Action": "accept",
    "Users": ["group:finance"],
    "Ports": ["100.100.300.1:8443"]
  }
],

Only members of the finance group can access the service on the specified port.

Scenario 3: Enforcing Protocol-Specific Restrictions

Suppose you want to allow SSH access to all servers for the IT support team, but you want to restrict SSH access from outside the office for everyone else.

Defining Groups and Tags

Create a group for the IT support team and a tag for office-based devices.

"Groups": {
  "group:it-support": ["eve@example.com", "frank@example.com"]
},
"Tags": {
  "tag:office": ["100.100.400.1", "100.100.400.2"]
}

ACL Rules

"ACLs": [
  {
    "Action": "accept",
    "Users": ["group:it-support"],
    "Ports": ["*:22"]
  },
  {
    "Action": "accept",
    "Users": ["group:all-users"],
    "Ports": ["tag:office:22"]
  }
],

In this scenario, the IT support team can SSH into any server regardless of location, while other users can only SSH from devices tagged as being in the office.

Scenario 4: Dynamic Access Based on Device Tags

Imagine you want to give contractors access to specific devices without exposing your entire network.

Defining Groups and Tags

Create a group for contractors and tags for the devices they should access.

"Groups": {
  "group:contractors": ["gary@example.com", "helen@example.com"]
},
"Tags": {
  "tag:contractor-device": ["100.100.500.1", "100.100.500.2"]
}

ACL Rules

"ACLs": [
  {
    "Action": "accept",
    "Users": ["group:contractors"],
    "Ports": ["tag:contractor-device:*"]
  }
],

This rule allows contractors to connect to the devices with the contractor-device tag on any port.

Conclusion

These examples provide a glimpse into the versatility and strength of Tailscale's ACLs. When configuring ACLs, always start with the principle of least privilege, giving users only the access they need to perform their roles. Regularly review and update your ACLs as your network evolves.

Remember, these are JSON configurations, so ensure that your syntax is correct to avoid errors. Use Tailscale's admin console to apply these ACLs, and always test your configurations to confirm that they work as intended.

Tailoring access controls is a dynamic process that requires ongoing attention. By continuing to refine your Tailscale ACLs, you'll maintain a secure, efficient, and well-organized network.