4 ms·

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 ye

by ghthor 6mo 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 6mo 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 6mo 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 5mo 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.

by ghthor 6mo ago

andrew-d 6mo 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 6mo 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 5mo 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.