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#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:
As of about a month ago, you can also sign up to Tailscale with any OIDC-compatible identity provider, so if you don't want to use Gmail or Microsoft you can self-host your own!
Yeah, as someone also on a TN, I'd love to hear more. I'd also love to know what the renewal process has been like for people that have been in the USA for a while (I've been here for 4 years and am looking to renew next October).
For what it's worth, that's a fair concern. I offer two things that make it not quite as bad as you may think, though :-)
1. We don't expect applicants to be amazing at this already. Having a background in security is good, of course, but not necessary. As a data point: in the office I work out of, we have someone who used to work in a bakery, someone who worked for an insurance company, and several people who had never done security before applying to Matasano. It's my opinion that you generally learn more "on the job", as it were, than you would preparing for an interview anyway. @tptacek's post at [0] is a good example of the type of people we have working for us.
2. We generally send candidates resources to help them prepare - I believe a couple recent applicants got free copies of "The Web Application Hacker's Handbook" [1].
If you or your friends are interested, you should check out Matasano (disclaimer: I work there). Our hiring process is much more focused on work-samples, and the in-person interviewing is pretty laid-back. We're also very up-front with candidates about what to expect and where they are in the process. Check out our careers page:
I recently started programming in Lua too - it's a fantastic language if you want to embed it in anything, and using the LuaJIT FFI [0] makes interfacing with C code from pure Lua a pleasure. I've also started writing a set of extension libraries[1] that provide various "missing" features - mostly inspired by Ruby.
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#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: