Learn Tailscale - Access Control: ACL & Tags

#Introduction

Up to episode 5, every node in the tailnet could reach every other. That's convenient for experimenting, but dangerous for production. Imagine your home NAS suddenly accessible from a coworker's laptop just because they're on the same tailnet. This is the problem solved by ACLs (Access Control Lists).

Episode 6 covers Tailscale's core security system: the ACL file in the admin console, the concept of allow rules, the default-deny principle, plus tags and groups for building managed policies. After this episode, you'll be able to design a secure tailnet from the start.

#ACL Concepts

#What Is the ACL File

An ACL in Tailscale is a HuJSON file (JSON with comments) managed in the admin console under Access Controls. This file determines who can access what — packets, ports, and features. The most basic rule has the form src → dst:

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

The rule above allows every user to access every node on every port. This is the default when a new tailnet is created.

#The Default Deny Principle

Tailscale doesn't allow anything unless the ACL explicitly states it. So the ACL file is a list of exceptions to default deny. Every rule has three parts:

• action: accept to allow.
• src: who is allowed (user, group, or tag).
• dst: what can be accessed (node:port or network range).

{
  "acls": [
    { "action": "accept",
      "src": ["user1@example.com"],
      "dst": ["server-prod:22"] }
  ]
}

The rule src: user1@example.com, dst: server-prod:22 allows only that user to access port 22 of the server-prod node.

#Tags and Groups

#Why Tags Are Needed

For automated devices (servers, CI, containers), user-based login doesn't fit — devices don't have human accounts. Tags move authorization from users to device categories. Tags always start with tag: and are managed by admins in the ACL file.

sudo tailscale up --advertise-tags=tag:server

The sudo tailscale up --advertise-tags=tag:server command requests the tag:server tag from the admin. Tag approval is controlled by the tagOwners block in the ACL.

#Defining tagOwners

Only admins can grant tags. The tagOwners rule determines who is allowed to assign a specific tag:

{
  "tagOwners": {
    "tag:server": ["group:devops"],
    "tag:workstation": ["user1@example.com"]
  },
  "acls": [
    { "action": "accept",
      "src": ["tag:server"],
      "dst": ["tag:workstation:22"] }
  ]
}

In the block above, tag:server can only be assigned by members of group:devops, and all nodes tagged server may access port 22 of nodes tagged workstation.

#Groups: Grouping Users

Besides tags, ACLs can use groups — a set of users from an identity provider (Google Workspace, Entra ID, GitHub). For example, group:engineering uses the provider's definition rather than a manual list. This keeps policies consistent with your organization.

#Building Managed Policies

#Common ACL Patterns

{
  "acls": [
    { "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:server:*"] },
    { "action": "accept",
      "src": ["user1@example.com"],
      "dst": ["nas-home:22,80,443"] }
  ],
  "ssh": [
    { "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:server"],
      "users": ["autogroup:nonroot", "root"] }
  ]
}

Notice the details:

• The rule src: ["group:devops"], dst: ["tag:server:*"] gives all devops members full access to all server nodes.
• The second rule limits NAS access to ports 22, 80, and 443 only.
• The ssh block sets Tailscale SSH policy separately — we cover it in episode 7.

#Testing ACL Changes

Every ACL change takes effect immediately. Always save and test from both sides: run tailscale ping from a source node to a destination node, and make sure nodes that aren't allowed are actually denied. Check the effect quickly with:

tailscale ping nas-home
tailscale status

#Best Practices

• Start from default deny and open only what's needed (least privilege).
• Use tags for automated devices, groups for humans.
• Limit ports, not *:*, for sensitive services.
• Review the ACL file regularly and version it in a repository (episode 17).

#Closing

Episode 6 introduced Tailscale's first and most important security layer: ACLs. You can control who accesses what, use tags for automated devices, groups for humans, and assemble managed policies.

Key takeaways:

• An ACL is a HuJSON file that governs access in the tailnet.
• Default deny: nothing is accessible without an explicit rule.
• Every rule consists of action, src, and dst.
• Tags (tag:server) are for automated devices, managed via tagOwners.
• Groups map users from an identity provider.
• Limit ports on sensitive services and always test after changing the ACL.

In the next episode, episode 7, we'll cover Tailscale SSH — enabling tailnet-identity-based SSH with tailscale up --ssh and tailscale ssh <host>, eliminating password and SSH key management, and configuring per-user and per-group SSH access through the ssh block in the ACL.