Summary:
Tailscale’s “auto approvers” feature seems to me to to be a practical necessity for automated creation of virtual infrastructure which includes machines that cannot or will not run tailscale but that must be reachable via one’s tailnet.
Its documentation, unlike that of most aspects of Tailscale, is quite sparse and is at least vaguely inconsistent.
Can anyone confirm that this auto approver status applies not so much to a set of zero or more users, as clearly indicated in the documentation, but to a set of zero or more devices (a.k.a., machines or nodes)–a set that is defined as the union of those machines that were placed on a tailnet by any of certain users and those machines to which any of certain ACL tags are currently applied?
Specifics:
In early 2022, Tailscale introduced “auto approvers for routes and exit nodes”. In that blog post, Maisem Ali (@maisem) wrote:
We’re introducing the concepts of
autoApprovers
for routes and exit nodes. This lets you specify in your ACL file which users can self-approve routes and exit nodes. This means that you can set up a subnet router or an exit node with just one CLI command on the device.
That statement seems clear to me. In Tailscale network access controls (ACLs), one can specify that certain Tailscale users can cause a node on which Tailscale was started with indication that it should advertise routing to one or more subnets to begin advertising such without the usual requirement for someone to manually approve that in the Tailscale admin console.
Ali continues:
To set up a subnet router, install Tailscale on the device, enable IP forwarding, and then run tailscale up
--advertise-routes
. You then need an admin with access to the machines view in the admin console to review and approve the route settings. If you’re setting up many subnet routers, this can be cumbersome.
autoApprovers
allows you to delegate who can advertise routes or exit nodes. In this case, rather than requiring approval after the fact, a user who is specified in a route’sautoApprovers
can advertise that route (or a subset of it) on any device, without requiring further approval. This lets you easily set up multiple subnet routers at once, or move devices in your network.[…]
autoApprovers
allows you to delegate who can advertise routes or exit nodes. In this case, rather than requiring approval after the fact, a user who is specified in a route’sautoApprovers
can advertise that route (or a subset of it) on any device, without requiring further approval. This lets you easily set up multiple subnet routers at once, or move devices in your network.
Got it. Certain users can can be authorized to set up subnet routers without explicit approval of such setup by designating those users to be “auto approvers.”
Ali concludes:
To start using autoApprovers, add them to your ACL file in the admin console.
I followed that link to the referenced documentation. I found that the relevant section begins:
The autoApprovers section of the tailnet policy file defines the list of users who can perform certain actions without requiring further approval from the admin console.
This implies that the feature’s purpose may be broader than just advertising of subnets for routing, but it still clearly indicates that this applies to users.
Two paragraphs later, we find a warning about what will happen if an auto approver user is removed: Subnet routers providing routing to subnets that were implicitly approved for such routing will immediately stop advertising that routing. The docs are silent about whether those subnet routers will stop routing to the applicable subnets.
If the device is re-authenticated by a different user who cannot advertise the route or exit node, or the user who advertised it is suspended or deleted, the route or exit node is no longer advertised.
This potential outcome is unfortunate, as it means that the functioning of likely-critical virtual infrastructure may depend on certain Tailscale users–which seem to correspond exclusively to people, as Tailscale appears to have no concept of machine users–continuing to be associated with a tailnet:
In other words, if a person who was designated as an auto approver quits their job, is fired, disappears, or dies, any and all subnet routing they arranged via the auto approval mechanism will be broken unless and until manual intervention is made.
Then, we find a surprising suggestion for addressing the problem:
To avoid this, consider making an ACL tag an auto approver.
So, now we have indication that auto approver status is not just for users but also for tags.
This does not, technically, conflict with the earlier information, which did not state that said status is exclusively for users, but it seems to me that a large portion of readers will have assumed that only users could be auto approvers.
Regardless, it’s rather awkward to say that a tag, which is not itself an object, but rather is a piece of information–a label, really–that can be applied to an object, can be an auto approver. A tag does not do anything; it indicates something about the object(s) to which it is applied.
The doc then states that an autoApprovers
definition looks like this:
"autoApprovers": {
"routes": {
"10.0.0.0/24": ["group:engineering", "alice@example.com", "tag:foo"],
},
"exitNode": ["tag:bar"],
}
Ignoring the exitNode
JSON object for now, I am guessing that the routes
object in this example indicates that a node may, without explicit administrative approval, advertise and provide routing to 10.0.0.0/24
only if one or more of the following is true:
- The user who created the node is among those in a user group called
group:engineering
. - The user who created the node is
alice@example.com
. - The node is currently tagged with a tag named
tag:foo
.