How to approach Tailscale security and compliance

What is Tailscale & why you’d use it

Tailscale is a zero-config VPN that uses peer-to-peer technology to connect end-user devices, mobile devices, and cloud or on-prem servers. It allows teams to create a secure connection between home networks and isolated VPCs without having to expose any device to inbound network traffic. Once your devices are all connected to your tailscale network (called a tailnet), they have their own 100.x.y.z IP address. Tailscale even has support for registering a device’s tailscale IP address into a shared DNS environment that’s dedicated to your organization.

For nimble or remote-first organizations, Tailscale changes how network security is done. Gone are the centralized network teams managing expensive corporate firewalls. With a zero-trust network like Tailscale, the DevOps engineers are empowered to add devices to the network. Microsegmentation becomes possible - not just in your cloud VPC using fine grained security groups, but between your cloud servers and end-user devices too.

You can configure devices on your tailnet to be an exit node. Other devices can then route all their traffic to the exit node. Great if I’m Kuala Lumpur and I need to download the latest episode of House of Dragons via my home exit node.

How Tailscale works

Tailscale is built on top of the open source Wireguard project. Using Tailscale’s coordination servers, it allows each device on the tailnet network to advertise its location and exchange cryptographic keys. Each session between two nodes on the tailnet is point-to-point. Traffic doesn’t flow through the coordination servers. If both sides are behind NAT gateways, Tailscale uses NAT Traversal to create the point-to-point connection.

End users login to Tailscale via their Single Sign On identity. They can then register their end-user device into the tailnet and receive an RFC6598 (100.64.0.0/10) IP Address.

Tailnet administrators can create authentication keys that allow servers to join the tailnet. These auth keys can be one-off or reusable, and they can add persistent or ephemeral devices to the network. Ephemeral devices are automatically purged from the tailnet when they go offline and are great for auto-scaling instances in the cloud.

Every tailnet is defined by a "Human JSON" file that defines which devices can communicate with each other, which users can communicate with which devices, how devices get tagged and who is allowed to approve devices joining the tailnet.

Since every device now has two IP addresses, the corporate one and the tailnet one, DNS resolution becomes an issue. Tailscale provides two answers to this: First, you can assign hostnames in the tailnet JSON configuration file. Second you can enable MagicDNS a beta feature from Tailscale that intercepts DNS traffic and will respond with the 100.x.y.z tailnet IP address for a particular host.

Enterprise Security concerns with Tailscale

Since Tailscale is built on the WireGuard protocol, the underlying technology is reasonably battle tested. But the technology introduced by tailscale is new and strange. Most normal firewall and VPN management tools & processes won’t work. If I put on my compliance hat, the major issues with enterprise use of Tailscale are:

1. Asset Management - By default, users in the Tailnet can add any instance to that Tailnet.
2. IP Address Management - Now every device has its corporate network IPv4 address in addition to its 100.60.0.0/10 Tailnet IP Address. While the tailnet and coordination servers will manage the assignment of the addresses, how do I ensure an up-to-date inventory of what device is using which 100.x.y.z address?
3. Secrets Management - Tailnet admins can create device pre-authorization keys. This is useful to allow ephemeral instances in the cloud to join the Tailnet, but these secrets allow anyone to join the network. They must be handled carefully.
4. Firewall Management - A Tailnet not centrally managed. New processes would have to be introduced to adhere to policies around firewall changes.
5. Network Segmentation is a hot trend, this sorta blows that out of the water. Your company's tailnet is a one big flat RFC6598 subnet. Tailscale supports microsegmentation, but now there are two networks to manage, so the complexity of network management has increased.
6. DNS Security - If you’re using DNS firewalls, or monitoring DNS for malicious activity, MagicDNS may provide a bypass to those controls and detections. As a network security practitioner, you want to ensure MagicDNS is configured to forward to your monitored and managed DNS servers.
7. Endpoint Security Tools - Many enterprises are adopting a strategy of ensuring devices that join the network have basic security controls enabled (Antivirus, EDR, etc). PaloAlto VPNs and Firewalls require devices to pass a Host Information Profile (HIP) Check before being allowed to connect. At this time, Tailscale doesn’t support any sort of host profiling.

All of this comes down to one core question: How to define a security baseline for the tool?

One positive compliance aspect to Tailscale is that there is no SSO Tax. In fact, there is no option to create a bespoke tailscale account. You must use Google, AzureAD or GitHub as an identity provider (Okta is also available for paid plans).

Leverage Steampipe to help govern your DevOps community’s use of Tailscale

Tailscale introduces a ton of new complexity for enterprise security teams to manage. User, device and IP management all have to take into account the company’s tailnet in addition to its corporate network.

Tailscale published a security best practices document that’s a good starting point. To help you visualize these best practices, you can use Steampipe to check your compliance to these recommendations with the Steampipe Tailscale Compliance mod.

Beyond the best practices from Tailscale, as a security practitioner I need to know:

1. What devices are on the network?
2. Who is using our tailnet?
3. What Auth keys exist, who created them and when do they expire?
4. How are ACLs being managed and do I have a micro segmented network?

Steampipe provides a convenient way to extract much of the data you’d need into your other inventory systems.

To get a list of all the devices and their IPv4 and IPv6 Tailnet addresses:

select
  name, os, user,
  jsonb_array_elements(addresses) as ip_address
from
  tailscale_device;

To get a list of all the users, and the groups they belong to:

with all_groups as (
  select
    tailnet_name,
    jsonb_object_keys(acl_groups) as group
  from
    tailscale_tailnet
)
select
  t.tailnet_name,
  g.group,
  jsonb_array_elements(t.acl_groups -> g.group) #>> '{}' as user
from
  tailscale_tailnet as t
  left join all_groups as g on t.tailnet_name = g.tailnet_name;

+--------------+--------------------+------------------+
| tailnet_name | group              | user             |
+--------------+--------------------+------------------+
| room17.com   | group:security     | chris@room17.com |
| room17.com   | group:room17-admin | chris@room17.com |
| room17.com   | group:room17-admin | chris@turbot.com |
+--------------+--------------------+------------------+
    

Finally a way to view the access lists:

select action, source, destination from tailscale_acl_entry;

+--------+------------------------+----------------------+
| action | source                 | destination          |
+--------+------------------------+----------------------+
| accept | ["autogroup:members"]  | ["*:443"]            |
| accept | ["*"]                  | ["tag:cloud:22"]     |
| accept | ["group:room17-admin"] | ["*:*"]              |
| accept | ["group:security"]     | ["*:443","splunk:*"] |
+--------+------------------------+----------------------+
    

Conclusion

The techniques we've shown here hopefully give you a better idea how you can manage the security and compliance of Tailscale, but everyone's situation is unique and you may find a solution that works better for you. If so, please let us know: we love to learn from our community!