Auto approvers: Just who or what can be one? Docs are unclear

ACL (Access Control Lists)
1

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’s autoApprovers 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’s autoApprovers 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:

  1. The user who created the node is among those in a user group called group:engineering.
  2. The user who created the node is alice@example.com.
  3. The node is currently tagged with a tag named tag:foo.
2

I engaged Tailscale support about this matter.

DeAndre Harris from Tailscale replied:

The auto approver of a route or exit node can be a user’s full login email address, a group name, or a tag — this is noted in the docs.

I responded:

The docs state, “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.”

What is a tag’s involvement in defining the list of such users?

I understand how one or more email addresses and group names can define a list of users–just not a tag. Tags would seem to define a list of nodes, not of users, since one can tag a node, but cannot tag a user. This is what led me to theorize that auto approver is a status that applies to nodes, not to users.

DeAndre continued:

In Tailscale, a tag is an object which can own nodes.

I responded:

On the page you referenced, ACL tags are defined, “ACL tags are similar to role accounts, but more flexible: you can assign many tags to a device, whereas a device can only be signed in as a single user.”

What you wrote, when taken along with this, implies that a node can have multiple owners. Is that accurate?

This also implies that the owner(s) of a node can change. Is that accurate?

3

If you use tags, multiple tags can be applied, and the effect is cumulative. IE: if the Tag “group 1” has access to device 1 but nothing else, and Tag “group 2” has access to device 2 and nothing else, then a device that is tagged with both “group 1” AND “group 2” would have access to device 1 and 2.

Tags replace the user account, so you can’t have both tags AND a user own a device.

You can have multiple tags applied to a device, but if a user owns a device, there can be only 1 user. (and again, you can’t have both tags and a user).

4

I read the first part of that sentence to mean, “Each device on a tailnet has zero or more ACL tags.”

My understanding is that the effect of ACL tags is entirely based on what, if any, conditions in a tailnet’s network access controls vary based on whether or not a given device has a given tag.

I don’t understand how a tag can have access to anything. It’s just a tag. I believe that network access controls could be written to specify that devices with a certain tag are allowed access to a one or more other devices, but I don’t know how one could specify that devices tagged as such are prohibited from accessing any other devices.

The Tailscale docs state that “a device’s identity is the combination of all its tags (not the intersection).” Maybe that’s what @muzicman0 was getting at. This seems somewhat obvious to me, given how ACL tags are used. If we specify in our network access rules that 1) any device with tag:foo is allowed access to device1, and also 2) any device with tag:bar is allowed access to device2 and device3, then obviously, any machine with tag:foo and tag:bar will be allowed access to device1, device2, and device3.

It’s my understanding that a tag doesn’t do anything, but is an arbitrary string, defined by way of specifying one or more users as “owner(s)” of it in network access rules, that can be associated with one or more devices.

I suspect that @muzicman0 meant to state that a tailscale device has an “managed by” attribute, and that at any given time, that attribute is set to either A) one user or B) one or more tags. Or, possibly, that untagged devices have a single user as manager, and tagged devices do not have a manager. The Tailscale docs, in the context of describing how to filter a list of devices in the admin console, state that one can filter based on “whether a device is managed by a specified user or has a specified tag.”

The concept of a device being managed by a user–a person–seems clear to me. It maps well to the physical world. However, having it “managed by” one or more tags seems much less so.
And changing or removing a device’s manager by way of tagging that device is an action that I find non-intuitive and one that I think deserves greater clarity in the Tailscale documentation.