Sanity check on ACL hosts

ACL (Access Control Lists)
1

If I read the ACL documentation correctly, I cannot reference a host in an ACLs block without creating an entry for it in Hosts.

So - I have to define all my hosts in the ACL file even though they are defined as a part of being on a tailnet?

"ACLs": [
		// Match absolutely everything. Comment out this section if you want
		// to define specific ACL restrictions.
		{
			"action": "accept",
			"src":    ["group:admin"],
			"dst":    ["*:*"],
		},
		{
			"action": "accept",
			"src":    ["group:toptal"],
			"dst":    ["demo-com:5432"],
		},
	],

Unless I have demo-com defined, the ACL doesn’t validate.

	"Hosts": {
		"demo-com": "100.72.9.83",
	},

This seems counter intuitive to me. If a host is already on my tailnet, then I shouldn’t have to define it in the ACL. That’s how I feel it should work, but no matter what I do, if I don’t define the host, the ACL manager complains.

Do I need to script this out to pull out all the hosts, and add them Hosts section? This feels unnecessary, I’d like to know if I’m doing something wrong.

2

you could do:

"dst": ["100.72.9.83:5432"],

I believe.

Other things to look into is if you use the full qualified domain name of the tailnet, so something like “demo-com.tailxxxxxx.ts.net”.

And lastly, I would check your Tailscale DNS settings.

I am not sure if you can reference hostnames in your ACL or not, but these are the things I would try first.

3

Good thought on adding the ts.net domain, but it didn’t work.

It certainly seems like you can’t reference hosts without them being defined in the ACLs area.

Really odd if you have a lot of devices (we do). I don’t want to define them in the Hosts area, lol. Guess I’m writing some automations.

4

just to be sure, did you add the whole domain (.tail####.ts.net)?

5

Yep, i think so.

	"ACLs": [
		// Match absolutely everything. Comment out this section if you want
		// to define specific ACL restrictions.
		{
			"action": "accept",
			"src":    ["group:admin"],
			"dst":    ["*:*"],
		},
		{
			"action": "accept",
			"src":    ["group:toptal"],
			"dst":    ["demo-com.###.ts.net:5432"],
		},

Resulted in: (from the preview rules)

"demo-com.###.ts.net": invalid IPv4 address

I’ll keep playing with it.

6

it’s weird, because it sure seems like this should work.

CleanShot 2023-02-13 at 18.14.47
CleanShot 2023-02-13 at 18.14.47745×654 71.4 KB

the Hosts section in the documentation does reference the ACLs section.

7

type:

tailscale status

in a terminal on a PC that is logged into Tailscale. It will reply with some info, but the top line will be something like:

100.100.xx.xx hw-swittwer-pws hw-swittwer-pws.tail12345.ts.net windows

The ‘.tail12345.ts.net’ is what you may need to add. Still not sure if it will work, but that is the DNS name for the Tailnet.

8

nope, I just tried testing it on mine, and it appears that it doesn’t work. I’ll play around for a bit and if I get it to work, I will let you know.

9

I think the only way around this would be to use tags. But that could also get tedious depending on how many different tags you would need.

We use different tags to define our different groups (Sales, Tech Services, Operations, etc). Then we allow access based on tags. But if you have no logical separation like we do, it may not work for you the same as it does for us.

If it’s something you want to explore, I would be happy to help. In our case, we use subnet routers because we have a large network with way too many hosts to have Tailscale on everything. We allow access to certain subnets based on tags.

10

Yeah, I think you’re spot on with the ACL tagging strategy. I get the feeling this is the only way to handle it, without defining everything in the ACL markup.

I have security concerns though, it seems any client can assign themselves a tag with --advertise-tags. If you have a bad actor on your tailnet, they could assign themselves a tag that you don’t want them to have. I could be thinking wrong here, but seems like it’s possible.

11

That’s a great idea, and very obvious. I’m kinda disappointed in myself I didn’t consider that. We are also looking to manage a slew of nodes, and it feels daunting to manage them all via this ACL markup. Setting up single network gateways would be much more manageable. Thanks for the tips!

12

You can define those subnets in the ACL for ‘readability’. For instance, our ACL Hosts section is similar to:

{
	// Readable shorthands for devices and networks.
	"hosts": {
		"wan-network":        "10.254.254.0/24",
		"corp-network":       "10.99.0.0/16",
		"unsecure-network":   "10.101.0.0/24",
		"management-network": "10.100.254.0/24",
		"experience-center":  "10.99.1.0/24",
		"HWAD01":             "10.99.10.9",
		"HWAD2":              "10.99.10.10",
		"HWSTORE01":          "10.99.10.13",
		"HWWIKIINT":          "10.99.10.15",
		"office-printer":     "10.99.0.13",
	},

This allows us to specify which subnets certain groups have by name. Some of the above definitions overlap, for example, the ‘experience-center’ subnet is within the ‘corp-network’ definition. This allows me to give certain tags unrestricted access to the entire 10.99.0.0/16 network, and other tags only access to the 10.99.1.0/24 networks.

13

I just tested this, and what I see is if someone tries to advertise tags that they are not authorized for, it will fail. The tag will actually be applied, however, the key will expire (even if it’s set to never expire). This is great, because then as an admin, I can see that someone tried, and take appropriate action (either approve it, or not). The user that tried will get a notice that authorization failed.

1 Like
14

That’s awesome, I had this in my todo’s to test. Thank you!
I think the tagging solution is going to work out just fine in this case.

1 Like