headscale/docs/acls.md

# ACLs use case example

Let's build an example use case for a small business (It may be the place where
ACL's are the most useful).

We have a small company with a boss, an admin, two developers and an intern.

The boss should have access to all servers but not to the user's hosts. Admin
should also have access to all hosts except that their permissions should be
limited to maintaining the hosts (for example purposes). The developers can do
anything they want on dev hosts but only watch on productions hosts. Intern
can only interact with the development servers.

There's an additional server that acts as a router, connecting the VPN users
to an internal network `10.20.0.0/16`. Developers must have access to those
internal resources.

Each user have at least a device connected to the network and we have some
servers.

- database.prod
- database.dev
- app-server1.prod
- app-server1.dev
- billing.internal
- router.internal

![ACL implementation example](images/headscale-acl-network.png)

## ACL setup

Note: Namespaces will be created automatically when users authenticate with the
Headscale server.

ACLs could be written either on [huJSON](https://github.com/tailscale/hujson)
or Yaml. Check the [test ACLs](../tests/acls) for further information.

When registering the servers we will need to add the flag
`--advertised-tags=tag:<tag1>,tag:<tag2>`, and the user (namespace) that is
registering the server should be allowed to do it. Since anyone can add tags to
a server they can register, the check of the tags is done on headscale server
and only valid tags are applied. A tag is valid if the namespace that is
registering it is allowed to do it.

Here are the ACL's to implement the same permissions as above:

```json
{
  // groups are collections of users having a common scope. A user can be in multiple groups
  // groups cannot be composed of groups
  "groups": {
    "group:boss": ["boss"],
    "group:dev": ["dev1", "dev2"],
    "group:admin": ["admin1"],
    "group:intern": ["intern1"]
  },
  // tagOwners in tailscale is an association between a TAG and the people allowed to set this TAG on a server.
  // This is documented [here](https://tailscale.com/kb/1068/acl-tags#defining-a-tag)
  // and explained [here](https://tailscale.com/blog/rbac-like-it-was-meant-to-be/)
  "tagOwners": {
    // the administrators can add servers in production
    "tag:prod-databases": ["group:admin"],
    "tag:prod-app-servers": ["group:admin"],

    // the boss can tag any server as internal
    "tag:internal": ["group:boss"],

    // dev can add servers for dev purposes as well as admins
    "tag:dev-databases": ["group:admin", "group:dev"],
    "tag:dev-app-servers": ["group:admin", "group:dev"]

    // interns cannot add servers
  },
  // hosts should be defined using its IP addresses and a subnet mask.
  // to define a single host, use a /32 mask. You cannot use DNS entries here,
  // as they're prone to be hijacked by replacing their IP addresses.
  // see https://github.com/tailscale/tailscale/issues/3800 for more information.
  "Hosts": {
    "postgresql.internal": "10.20.0.2/32",
    "webservers.internal": "10.20.10.1/29"
  },
  "acls": [
    // boss have access to all servers
    {
      "action": "accept",
      "users": ["group:boss"],
      "ports": [
        "tag:prod-databases:*",
        "tag:prod-app-servers:*",
        "tag:internal:*",
        "tag:dev-databases:*",
        "tag:dev-app-servers:*"
      ]
    },

    // admin have only access to administrative ports of the servers
    {
      "action": "accept",
      "users": ["group:admin"],
      "ports": [
        "tag:prod-databases:22",
        "tag:prod-app-servers:22",
        "tag:internal:22",
        "tag:dev-databases:22",
        "tag:dev-app-servers:22"
      ]
    },

    // developers have access to databases servers and application servers on all ports
    // they can only view the applications servers in prod and have no access to databases servers in production
    {
      "action": "accept",
      "users": ["group:dev"],
      "ports": [
        "tag:dev-databases:*",
        "tag:dev-app-servers:*",
        "tag:prod-app-servers:80,443"
      ]
    },
    // developers have access to the internal network through the router.
    // the internal network is composed of HTTPS endpoints and Postgresql
    // database servers. There's an additional rule to allow traffic to be
    // forwarded to the internal subnet, 10.20.0.0/16. See this issue
    // https://github.com/juanfont/headscale/issues/502
    {
      "action": "accept",
      "users": ["group:dev"],
      "ports": ["10.20.0.0/16:443,5432", "router.internal:0"]
    },

    // servers should be able to talk to database. Database should not be able to initiate connections to
    // applications servers
    {
      "action": "accept",
      "users": ["tag:dev-app-servers"],
      "ports": ["tag:dev-databases:5432"]
    },
    {
      "action": "accept",
      "users": ["tag:prod-app-servers"],
      "ports": ["tag:prod-databases:5432"]
    },

    // interns have access to dev-app-servers only in reading mode
    {
      "action": "accept",
      "users": ["group:intern"],
      "ports": ["tag:dev-app-servers:80,443"]
    },

    // We still have to allow internal namespaces communications since nothing guarantees that each user have
    // their own namespaces.
    { "action": "accept", "users": ["boss"], "ports": ["boss:*"] },
    { "action": "accept", "users": ["dev1"], "ports": ["dev1:*"] },
    { "action": "accept", "users": ["dev2"], "ports": ["dev2:*"] },
    { "action": "accept", "users": ["admin1"], "ports": ["admin1:*"] },
    { "action": "accept", "users": ["intern1"], "ports": ["intern1:*"] }
  ]
}
```