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 in a timely manner
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 security bulletins
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.
Subscribe via RSS or follow @TailscaleSec on Twitter.
Set a contact for security issue emails
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.
If you want multiple users to be notified, consider using an email group. For example, use firstname.lastname@example.org, instead of email@example.com, for security issue notifications.
Enable MFA in your identity provider
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 in ACLs
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 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.
Define tags in ACLs, and use these as part of access rules. Use an auth key with an ACL tag so that a device is automatically tagged when it is authenticated.
Use check mode for Tailscale SSH
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.
Use session recording for Tailscale SSH
Set up session recording to log the contents of Tailscale SSH sessions. Session recording for Tailscale SSH streams these recordings to special recorder nodes in your tailnet, and Tailscale never has access to these recordings. You can deploy the recorder nodes as Docker containers, and configure recordings to be stored on the Docker host’s disk or in AWS S3 (and other S3-compatible object storage services). Session recording is only available for Tailscale SSH connections.
Follow these instructions to deploy the recorder nodes and update your ACLs to require session recording.
Review configuration audit logs
Review who did what, and when, in your tailnet. Configuration audit logs record actions that modify a tailnet’s configuration, including the type of action, the actor, the target resource, and the time.
Regularly review the logs, and if needed, use the Tailscale API to export the logs for long term storage.
Get notified about events on your tailnet
Use webhooks to subscribe to events. Webhooks allow you to subscribe to certain events on your Tailscale network and process the event notifications through an integration or app. For example, you can subscribe to events like adding a node or updating your tailnet policy file, and then receive the event notifications in a Slack channel or other app.
Subscribe to tailnet management events to be notified of changes to your tailnet policy file, new nodes, new users, and more.
Offboard users when they leave
Suspend or delete users as part of your offboarding process. Offboarding Tailscale users ensures that they no longer have access to resources including machine authorization, API keys, and auth keys.
Automatically or manually suspend users when they leave. This process can vary depending on your identity provider and whether or not you use user & group provisioning (SCIM).
For more information, see Offboarding users.
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.
Use ACL tests in ACLs
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 Admin roles
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.
Assign the roles of Admin, Network admin, IT admin, Billing admin, and Auditor in the users tab of the admin console.
Enable device approval
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.
Enable device approval from the settings tab of the admin console.
Customize node key expiry
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.
Modify key expiry from the settings tab of the admin console.
Protect your network boundary
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.
Set up a firewall for your network or for your device. See Using Tailscale with your firewall for additional configuration information.
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 General settings page of the admin console. Note that certificates are added to the Certificate Transparency log, so machine names should not contain private information.
Remove unused API and auth keys
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.
Prevent DNS rebinding attacks
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:
Manage ACL updates with GitOps
Use GitOps to keep the source of truth for your tailnet policy file in code, outside of the Tailscale admin console, and use features in a code repository tool to manage and version ACLs. Use GitOps for Tailscale ACLs to manage your tailnet policy file in a code repository, and use protected branches and required reviews to manage changes. Using GitOps also allows versioning and an audit trail of changes to your tailnet policy file.
For example, you can require approvals by specific individuals, or enforce tests pass successfully before merging a change.
Set up Tailscale with infrastructure as code
Use infrastructure as code tools to deploy Tailscale infrastructure programmatically. By using an infrastructure as code tool for deployment, you can deploy (or redeploy) a consistent or prior version of a configuration in case of an issue.
Set up the Terraform or Pulumi Tailscale providers to interact with the Tailscale API. Supported features include the ability to define your tailnet policy file, set DNS settings, generate auth keys, and manage device properties. Restrict access to the Tailscale API to your infrastructure as code tools, so that all configuration changes are centrally managed.
Use Network flow logs
Use Network flow logs to determine how nodes are connecting on your Tailscale network. When Network flow logs are enabled and clients are running a sufficient client version, and when not using
tailscaled --no-logs-no-support, nodes report their network activity to the Tailscale logs service. These logs can be accessed using the Tailscale API.
Regularly review the logs, and if needed, export the logs for long term storage.