Best practices to secure your tailnet
Tailscale has many security features you can use to increase your network security. This page provides best practices for using these features to harden your Tailscale deployment.
See also an overview of Tailscale’s security, including how Tailscale builds in security by design, and internal controls we use to help keep your information safe.
Baseline practices are widely applicable and high-value steps to improve security.
Upgrade Tailscale clients regularly, in a timely manner. Tailscale frequently introduces new features and patches existing versions, including security patches.
Manual updates are required for Linux and Windows devices; updates for iOS, Android, and macOS devices are automated. Use the Machines tab of the admin console to see devices in your tailnet, what version of Tailscale they are running, and if they can be updated. You can also filter for machines that have an update available by using the
Subscribe to Tailscale’s security bulletins. Tailscale publishes security bulletins to disclose security issues affecting Tailscale. If you’re directly affected by a security issue, and we have your contact information, we will contact you.
Set a contact for security issue emails. If you’re directly affected by a security issue, and we have your contact information, we will contact you. If no email is set for a security contact, Tailscale uses the default behavior, which is to send security issue emails to the tailnet owner email address.
Enable multi-factor authentication in your identity provider for authenticating to Tailscale, ideally using a hardware token. Tailscale relies on your existing identity provider to authenticate users. Any authentication settings from your identity provider are automatically used by Tailscale, including MFA and context-aware access.
Follow your identity provider’s documentation for how to enable multi-factor authentication.
Restrict access to users based on job function and what they need to access. See ACL samples for common scenarios.
Use groups to manage your users. Using groups allows identities to be controlled based on job function. If someone leaves an organization or changes roles, you can adjust the group membership rather than update all of their ACLs.
Define groups in ACLs for sets of users, and use these as part of access rules. Enable user & group provisioning to sync users and groups from your identity provider, to automatically add or suspend users, and use groups in ACLs.
Use tags to manage devices. Using tags allows you to define access to devices based on purpose, rather than based on owner. If someone leaves an organization or changes roles, common devices they have set up, like a server, will not need to be reconfigured.
Verify high-risk Tailscale SSH connections with check mode. Check mode requires certain connections, or connections as certain users (such as
root), to re-authenticate before connecting. This allows the user to access these high-risk applications for the next 12 hours or for a specified
check period before re-authenticating again. Check mode is only available for Tailscale SSH connections.
In an ACL’s
ssh rule, set the
action field to
check to configure check mode for your high-risk Tailscale SSH connections.
Advanced practices may not be widely applicable. They may also include features which require more configuration or a more advanced knowledge of security and networking.
Write tests to ensure access controls don’t change unexpectedly. ACL tests let you ensure that your access controls are as expected, so that after making a change, an important permission isn’t accidentally revoked, or a critical system accidentally exposed.
Define ACL tests in ACLs. These are automatically validated when an ACL is updated.
Assign user roles for managing Tailscale as appropriate, based on job function and for separation of duties. Tailscale provides multiple user roles that restrict who can modify your tailnet’s configurations. These allow for separation of duties between admins who can modify users and devices, such as IT administrators, and those who can modify network configurations, such as the networking team.
Require devices to be approved before they join your network. You can require that new devices be manually reviewed and approved by an Admin before they can join the network. This can be used to ensure only trusted devices, such as workplace-managed laptops and phones, can access a network.
Require users to rotate keys by re-authenticating their devices to the network regularly. Devices connect to your tailnet using a public node key which expires automatically after a period of time, forcing keys to rotate. By default, Tailscale requires devices to re-authenticate every 180 days, but some organizations may have a need for stricter controls.
Restrict access to your private network, e.g., using a firewall. Tailscale allows you to easily connect your devices no matter their local area network, and ensures that traffic between your devices is end-to-end encrypted. However, Tailscale does not protect your devices from any other traffic.
Obtain public TLS certificates for internal web tools hosted on your network. Connections between Tailscale nodes are already secured with end-to-end encryption. However, browsers are not aware of that because they rely on verifying the TLS certificate of a domain. By getting a TLS certificate from a public CA for your internal web tool, you avoid confusing your users with browser security warnings.
Configure HTTPS for your tailnet from the feature settings tab of the admin console. Note that certificates are added to the Certificate Transparency log, so machine names should not contain private information.
Regularly remove API and auth keys that are no longer needed for your network. This prevents leaked keys being used to add unauthorized users or devices to your network.
View existing API and auth keys from the key settings tab of the admin console, and remove those you no longer need. If you are using an auth key to only authenticate a single device, consider using a one-time auth key.
Ensure a Host header is present for HTTP services. Web services available in a tailnet over HTTP (not HTTPS) may be susceptible to DNS rebinding attacks, where a Tailscale node visiting a malicious web page can be triggered to run a client-side script and attack other nodes in the tailnet. HTTP services can detect DNS rebinding attacks by validating the Host header of incoming HTTP requests is allowlisted.
Set a Host header field in HTTP request messages sent to a HTTP service running in your tailnet. For example, in the HTTP request message, set:
GET /resource HTTP/1.1 Host: www.example.com
This could also be a MagicDNS fully qualified domain name, for example: