Add support for autoApprovers ACL

[tsujamin]

• read the CONTRIBUTING guidelines
• raised a GitHub issue or discussed it on the projects chat beforehand
• added unit tests
• added integration tests
• updated documentation if needed
• updated CHANGELOG.md

I've patched in support for AutoApprovers for exit nodes and subnets per https://tailscale.com/blog/auto-approvers/

The behaviour of the code is (currently)

• Support auto-approving nodes that advertise subnets or exit status by tag, group or namespace
• Advertised routes can be auto-approved by a overarching autoApproved route (e.g. advertised route 10.10.0.0/16 would be enabled if the node matched autoApproved route 10.0.0.0/8)
• EnableAutoApprovedRoutes is called in protocol_common_poll.go!handlePollCommon, although I'm not 100% sure if this is the appropriate place within headscale

Let me know what you think, happy to tweak as far as my limited go skills allow

[juanfont]

@tsujamin can you update the PR to fix the conflict and replace inet.af/netaddr with net/netip?

[tsujamin]

merged and refactored

[tsujamin]

linting issues fixed

[kradalby]

I think this looks pretty very good, I would have liked to see these kind of tests for functions like GetRouteApprovers.

We also need a CHANGELOG entry.

[kradalby]

I have one concern here, but feel free to let me know if I have missed it:

If a node advertise a route, and at the time it is accepted by the ACL autoapprove, what happens if it is removed from the ACL?

I believe the current behaviour would result in the route being left active, which is probably ok since the feature is Auto approve and not implying that it will keep the settings in sync. However we probably should call this out somewhere, not sure where tho.

@juanfont @restanrm

[tsujamin]

Yeah you're right - if a route advertised by a node is autoApproved under the current policy, and that policy changes, the route will remain approved. As far as I can gather this is similar to the SaaS offering's behaviour: once a route is auto-approved its up to the user to manage it from that point.

Let me know if there's a good place to docco it - another option could be (if my other preauthkey related PR is merged) writing a doc on how to use both features together and call out this behaviour there?

[kradalby]

If this resembles the upstream behaviour, which the name implies, that it will be approved and is not "state management", then it is fine.

You can document them together.

Another quick question, if a route is already announced by a node, but not approved, and then the autoApprove rule is added, will it get approved? Basically, is this evaluated when a node joins/sends an update, etc.

[tsujamin]

awesome - I can add a test like that but since the underlying logic relied on the same expandAlias logic I ommited it for now.

do you want me to do the change-log or is that something the maintainers do as a rollup?

[kradalby]

awesome - I can add a test like that but since the underlying logic relied on the same expandAlias logic I ommited it for now.

do you want me to do the change-log or is that something the maintainers do as a rollup?

You can add the changelog.

[tsujamin]

I've added the changelog - just noting though that there's a merge conflict between this and #767 so #767 would need to be merged first, then I can make the small change to a failing test here

[samcday]

I think this logic might be the wrong way around?

i.e if I have an auto approved prefix of 10.0.0.0/8 and then I try to advertise 10.1.0.0/24, I would expect autoApprovedPrefix.Bits() == 8 and prefix.Bits() == 24, or am I misunderstanding this?

I ask because I tried out the parent prefix thing and it doesn't seem to work for me. For now I'm going to add all 255 /24s I need to my ACL to move on xD. If I get some time later I might try forking and inverting this logic and see if it fixes my issue.

[tsujamin]

Yeah you're right, bugger but thanks for the find.

@juanfont @kradalby I'll write and submit a PR to fix this with a regression test

[samcday]

Wow, thanks for the speedy response. And also thanks for shipping this very hype feature :)

[tsujamin]

np, nothing good on tv right now 😂 should be fixed in #862 hopefully