4 ms·

I find it difficult to configure Tailscale for my use case because they seem to completely not support making ACL rules based on the identity of the device rath

I find it difficult to configure Tailscale for my use case because they seem to completely not support making ACL rules based on the identity of the device rather than a part of the address space. I'm not configuring a router here, I'm configuring a peer-to-peer networking layer... or at least I'm supposed to be...

spockz 7mo ago
I remember from the docs you can use node names. At the very least you can use tags for sure. Assign tags to nodes and define the ACL based on those.
- LoganDark 7mo ago
  Last I read the docs while troubleshooting this very problem, you cannot specify node names as the source or destination of a grant. You can specify direct IP address ranges, node groups (including autogenerated ones) or tags, but not names. Tags permanently erase the user identity from a device, and disable things like Taildrop. When I tried to assign a tag for ACLs, I found that I then could not remove it and had to endure a very laborous process to re-register a Tailscale device that I added to Tailscale for the express purpose of remotely accessing
  - ghthor 7mo ago
    You can ack based on groups, and you can out users into groups. So if you auth a node, it’s now your node and the ACL for your user / group will apply. But yes I don’t think you can ACL based o the hostname
    - andrew-d 7mo ago
      Hi there, I work at Tailscale. Part of the reason that we don't (currently) let you do this is that a hostname is a user-reported field, and can change over time; it's not a durable form of identity that you can write ACLs on. One could imagine, for example: 1. Creating an ACL rule that allows hostname "webserver" to hostname "db". 2. (time passes) 3. Hostname "webserver" is deleted/changed to "web"/etc. 4. Someone can now register a user device with the system hostname set to "webserver" Should they be allowed to inherit the pre-existing ACL rule? However, you can accomplish something very close to what you're asking for, I think, by defining a "host" in the policy file (https://tailscale.com/docs/reference/syntax/policy-file#hosts https://tailscale.com/docs/reference/syntax/policy-file#host...) that points to a single Tailscale IP. Since we don't allow non-admins to change their Tailscale IP, this uniquely identifies a single device even if the hostname changes, and thus you can write a policy similar to: "hosts": { "myhost": "100.64.1.2", }, "grants": [ { "src": ["myhost"], "dst": ["tag:db"], }, ]
      - LoganDark 7mo ago
        That's why my next instinct was to try specifying a node key, which does not change unless the device is re-registered, but that does not work either.
      - ghthor 6mo ago
        Yes I noticed that when designing our ACL usage. I didn’t find it all that useful unless we were inheriting some non tailscale systems with static IPs that we were going to subnet proxy to w/ tailscale. Tags are just a better way to do this for tailscale only nodes, as now the ACL doesn’t require any change during a device key rotation.
codethief 7mo ago
> because they seem to completely not support making ACL rules based on the identity of the device rather than a part of the address space Could you rephrase that / elaborate on that? Isn't Tailscale's selling point precisely that they do identity-based networking? EDIT: Never mind, now I see the sibling comment to which you also responded – I should have reloaded the page. Let's continue there!

spockz 7mo ago

I remember from the docs you can use node names. At the very least you can use tags for sure. Assign tags to nodes and define the ACL based on those.

LoganDark 7mo ago
Last I read the docs while troubleshooting this very problem, you cannot specify node names as the source or destination of a grant. You can specify direct IP address ranges, node groups (including autogenerated ones) or tags, but not names. Tags permanently erase the user identity from a device, and disable things like Taildrop. When I tried to assign a tag for ACLs, I found that I then could not remove it and had to endure a very laborous process to re-register a Tailscale device that I added to Tailscale for the express purpose of remotely accessing
- ghthor 7mo ago
  You can ack based on groups, and you can out users into groups. So if you auth a node, it’s now your node and the ACL for your user / group will apply. But yes I don’t think you can ACL based o the hostname
  - andrew-d 7mo ago
    Hi there, I work at Tailscale. Part of the reason that we don't (currently) let you do this is that a hostname is a user-reported field, and can change over time; it's not a durable form of identity that you can write ACLs on. One could imagine, for example: 1. Creating an ACL rule that allows hostname "webserver" to hostname "db". 2. (time passes) 3. Hostname "webserver" is deleted/changed to "web"/etc. 4. Someone can now register a user device with the system hostname set to "webserver" Should they be allowed to inherit the pre-existing ACL rule? However, you can accomplish something very close to what you're asking for, I think, by defining a "host" in the policy file (https://tailscale.com/docs/reference/syntax/policy-file#hosts https://tailscale.com/docs/reference/syntax/policy-file#host...) that points to a single Tailscale IP. Since we don't allow non-admins to change their Tailscale IP, this uniquely identifies a single device even if the hostname changes, and thus you can write a policy similar to: "hosts": { "myhost": "100.64.1.2", }, "grants": [ { "src": ["myhost"], "dst": ["tag:db"], }, ]
    - LoganDark 7mo ago
      That's why my next instinct was to try specifying a node key, which does not change unless the device is re-registered, but that does not work either.
    - ghthor 6mo ago
      Yes I noticed that when designing our ACL usage. I didn’t find it all that useful unless we were inheriting some non tailscale systems with static IPs that we were going to subnet proxy to w/ tailscale. Tags are just a better way to do this for tailscale only nodes, as now the ACL doesn’t require any change during a device key rotation.

codethief 7mo ago

> because they seem to completely not support making ACL rules based on the identity of the device rather than a part of the address space Could you rephrase that / elaborate on that? Isn't Tailscale's selling point precisely that they do identity-based networking? EDIT: Never mind, now I see the sibling comment to which you also responded – I should have reloaded the page. Let's continue there!