FR: boolean and combinatorial allow rules in ACL

[rocket-science-ch]

What are you trying to do?

In larger deployments with many users, defining access for 95% becomes a hassle without specifically naming every user in a group. Therefore, using autogroup:members is a good option. But what if you what everyone to be able to access a service, expect for these two external contractors (the 95% problem described above)?

How should we solve this?

I suggest a new description (e.g. the ! sign) to actively substract these users, groups or tags from the larger set mentioned:

"acls": [ { "action": "accept", "src": [ "autogroup:members", "!group:exclude_this_contractors" ], "dst": [ "git:443,80,22", "tag:external:*", ], },

What is the impact of not solving this?

No response

Anything else?

No response

[DentonGentry]

The intent with this is to synchronize group memberships with an external source that can apply whatever sophisticated membership criteria is desired.

• group sync for Okta is available now: https://tailscale.com/blog/sync-okta-groups/
• group sync for Active Directory is expected next: Sync identity provider groups and user deactivations from Active Directory using SCIM #979
• group sync for Google is planned, but harder as Google dropped support for the standard API for this function in 2019: Sync identity provider groups and user deactivations from Google Auth #2861

[rocket-science-ch]

My original intent is to do this independently of external groups, purely using ACL defined entries.

[DentonGentry]

related: #5290

[ShakataGaNai]

This, or DENY ACL ( #6915 ), is fairly important. We have groups that may have access to a majority of systems, like DevOps. Their SRC/DST ACL is effectively /:*. However, there may be small exceptions to that, such as systems/networks they shouldn't be able to access for security/compliance reasons.

Today the only answer is to move DevOps from /:* to listing out EVERY network/host/tag manually, EXCEPT the perhaps one network in question. During first time getting started, that's not a big deal. But as usage with Tailscale grows, that becomes more problematic. Now every time a new network is added, someone needs to remember to update that allow list for DevOps. Eventually, it'll become huge, unwieldy, and very hard to audit.

Where as it is much simpler, much more secure (since it's clearer and easier to read), and much less prone to human error... if there is simply a way to say "DevOps can access everything but X". If that's boolean logic or DENY ACL, doesn't matter, but it's really big oversight to not have this. Almost every firewall and ACL system from Cisco to IPTables, has a DENY equivalent.

[vsarunas]

Another vote for being to exclude a particular group/tag from an ACL.

[chernogorsky]

I have about 60 routes in my route tables with a single aggreage /16 for the site
so in order to filter one network for a group I have to put 59 routes in allow, and make sure I never use filtered route anythere else.

so, yes, any / all of action=deny, ![range] in src/dst, deny = [range] statement would be quite helpfull