FR: ACL with DNS resolution

[jonathan-wondereur]

What are you trying to do?

I am trying to put some IPs of my managed databases under the ACL controls using a subnet relay. The Database IP (internal IPv4) however changes from time to time, this means that I need to go manually update the ACL to reference the new internal IPv4 address.

How should we solve this?

Support using a DNS name instead of an IP address in the ACL file.

Replacing:

{
...
"Hosts": {
    "dev-pgsql-database": "10.118.48.3",
}
...

With:

{
...
"Hosts": {
    "dev-pgsql-database": "my.host.dns.name",
}
...
}

Would make my life a lot easier.

What is the impact of not solving this?

Manual work, and DB connections not working for my team until I can fix the issue.

Anything else?

No response

[DentonGentry]

Thus far we have declined to do this because hosts control their own hostname, making it trivially easy to bypass ACLs based on DNS name. The Hosts stanza in the ACL JSON is intended to provide a recognizable hostname while not allowing the actual node to have control over it.

[jonathan-wondereur]

I wonder if the Tailscale server could resolve the DNS name and replace it with a resolved IP before giving it to the client?

[DentonGentry]

The compiled ACL list is always Tailscale IP addresses, but the concern is that allowing ACLs to be written relying on something which an individual node ultimately controls.

Usually when ACLs are being written for specific nodes, instead of Users, it indicates a place where tags might be used instead. Tagging the node would mean:

1. ACLs can be written for the tag, instead of individual IP addresses
2. If ACLs are being written for the IP address it implies that the User who owns the node isn't the entity who should be supplying the access control at all.
3. Nodes cannot adjust their own tags, especially if they are created using an authkey with tags already applied

.

[madjam002]

I wonder if the Tailscale server could resolve the DNS name and replace it with a resolved IP before giving it to the client?

Introducing DNS into the ACLs seems problematic for the reasons mentioned, I guess it could resolve when the TTL expires but what if your database IP changes and the TTL hasn't expired? The ACL rules could then be pointed to a different node that has used the old IP, introducing a security risk. ACLs in Tailscale at the moment are nice because they are pushed rather than pulled (at least that is my understanding and observation from using it).

Instead I think a better idea would be to write a service that updates the ACL rules programatically or to use something like Consul Terraform Sync if you're using Consul/Terraform and the Terraform Tailscale provider. This way when the IP changes the updated ACL rules can be pushed to nodes immediately.

Or just use tags if the database server runs on a node with Tailscale installed.

[jonathan-wondereur]

The database is a managed DB, thus I can not install Tailscale on it.

Right now, when the provider changes the DB IP address with an upgrade the IP could be used for something else, potentially opening up a security issue as you point out, not to mention not working.

The TTL of the DNS record is pretty short, definitely shorter than the time it takes me to realize the IP has changed and update it. This DNS record is also public and controlled by the DB service provider, it is not based on the hostname of the VM.

One of the reasons we use Tailscale is it is so simple. We do not have anything like Consul Terraform Sync in our stack at the moment.

[DentonGentry]

Right now, when the provider changes the DB IP address with an upgrade the IP could be used for something else, potentially opening up a security issue as you point out, not to mention not working.

These IP addresses are not 100.64.0.0/10 addresses of Tailscale nodes, they are external IPs? (either actually public IPs, or private IPs like 172.16.0.0/10.0.0.0/192.168.0.0/etc)

When the IP address of one of those nodes changes, the desire is for Tailscale ACLs to shift to apply the same access controls to the new address?

Are the ACLs primarily controlling Tailscale nodes being able to connect to the external nodes, or control whether the external nodes can connect back through a subnet router to something on the tailnet?

[jonathan-wondereur]

1. Yes, they are actually private IPs, in this case, a 10.0.0.0 VPC network.
2. Yes, when the IP address of the node changes I would like to update the ACLs to provide the same access to the new IP address.
3. The ACLs in this case are controlling if the Tailscale nodes can connect through a subnet route to the node in question (Managed Database) on a VPC.

[RutledgePaulV]

@DentonGentry, I wonder if this could be solved in this way:

• Expand the specification for "hosts" in an ACL to allow assigning names to a set of non-contiguous IP addresses (like internal load balancer endpoints). It feels very arbitrary that these only allow a single IP address or single contiguous range today.
• Document how you can use a cronjob and the tailscale API to automate maintenance of the "hosts" section of the ACL by querying private DNS servers like Route53 and populating the "hosts" section with the IPs returned by resolving any A or CNAME records that resolve to IP addresses in your internal network.
• Now, you can reference any of those "hosts" by their domain name in your ACL rules and trust that the IP addresses will be continually updated by the aforementioned automation. Tailscale is then relieved of the potential security issues involved with local DNS resolution but still makes it possible to implement hostname based ACLs by having their customers define the mapping logic out-of-band.