![\"General](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fgeneral-rules.d8086c09.png&w=3840&q=75\")
Last validated: Dec 2, 2025
\nThe Tailscale visual policy editor gives you an interactive graphical interface for managing access control policies in a Tailscale network (known as a tailnet). This reference documents all interface elements, forms, controls, and their associated help information to help you effectively use the visual editor. For a comprehensive understanding of the underlying policy syntax, refer to Tailscale's policy syntax documentation.
\nRefer to the targets documentation for detailed information about available targets for sources, destinations, and other fields.
\n
General access rules control network-level and application-level access between devices in your tailnet using grants syntax. These rules determine which sources can connect to which destinations on specified ports and protocols. The visual editor translates these rules into the underlying grant structure in your tailnet policy file.
\nThe visual editor uses grants syntax on the backend. This means that if you create an access control policy using the ACL syntax in the JSON editor, it automatically converts to grants syntax when you edit the policy using the visual editor. Grants syntax supports all the same capabilities as ACL syntax with additional features like route filtering and app capabilities. Refer to grants versus ACLs for more information.
\nEach general access rule uses grants syntax, which consists of three main components: sources, destinations, and network restrictions. Grants also support additional components like the via field and app capabilities for more advanced access control scenarios. For a complete overview of grants syntax, refer to the grants syntax reference.
The rules table displays all configured access rules with their sources, destinations, and network restrictions. The ![\"ellipsis](\"https://tailscale.com/files/images/icons/fa-ellipsis-h.svg\"){kind=icon}
menu for each rule lets you edit and delete operations. For examples of common access patterns, refer to the grant examples.
![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fgeneral-rules-add.92ec3351.png&w=3840&q=75\")
To add a general access rule using the visual editor:
\nTo edit a general access rule using the visual editor:
\n menu of the rule to edit, then select Edit.To delete a general access rule using the visual editor:
\n menu of the rule to edit.There is no confirmation required, but you have a brief moment to undo the deletion.
\n![\"Tailscale](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftailscale-ssh.545e799c.png&w=3840&q=75\")
Tailscale SSH rules control SSH access to devices in your tailnet. These rules work alongside general access rules to provide secure SSH connectivity without managing SSH keys. The SSH implementation leverages your existing identity provider for authentication, eliminating the traditional complexity of SSH key distribution and rotation.
\nSSH rules extend basic network access with SSH-specific controls that enhance security and ease of management. Understanding these components helps you create SSH policies that balance security with usability.
\nThe Source field identifies who can start SSH connections. These typically include users or groups from your identity provider. The Destination field specifies which devices accept SSH connections, often identified by tags like tag:server or tag:bastion.
Destination users define which user accounts are accessible on the destination. You might specify autogroup:nonroot to prevent root access or use email-based matching to map identity provider users to local accounts. Check mode determines whether to require periodic re-authentication, adding an extra security layer for sensitive connections.
To add a Tailscale SSH rule using the visual editor:
\nautogroup:nonroot, root, or matching local users with email.12h).Enable Check mode for rules that let humans start SSH connections. This adds an authentication layer that verifies user identity before granting access. The Check period determines how long connections remain authorized before requiring re-authentication. Setting appropriate Check period values balances security with user convenience.
\nFor automated processes or service accounts, you might disable Check mode to prevent interruptions. However, these connections should have tightly scoped permissions and use tag-based identities rather than personal credentials.
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftailscale-ssh-edit.99acf768.png&w=3840&q=75\")
To edit a Tailscale SSH rule using the visual editor:
\n menu of the SSH rule to edit, then select Edit.To delete a Tailscale SSH rule using the visual editor:
\n menu of the SSH rule to delete.![\"Groups](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fgroups.e54632d5.png&w=3840&q=75\")
Groups organize users for simplified access control management. The Groups tab contains sections for user-defined groups, synced groups from identity providers, and built-in autogroups. Groups reduce policy complexity by letting you manage collections of users rather than individuals, making your policies more maintainable as your organization grows. For detailed information about group types and usage, refer to the targets documentation.
\nCreate and manage custom user groups to use in access control policies. Groups improve policy management by letting you reference collections of users rather than individuals. This abstraction makes policies more readable and reduces the maintenance burden when team membership changes.
\nChanges to group membership immediately affect all policies referencing that group.
\n![\"Create](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fgroups-add.96e3ae82.png&w=3840&q=75\")
To add a user-defined group using the visual editor:
\nTo edit a user-defined group using the visual editor:
\n menu of the group to edit, then select Edit.To delete a user-defined group using the visual editor:
\n menu of the group to delete.Synced groups automatically populate from your identity provider through SCIM integration. These groups are read-only in the visual editor. Membership changes must occur in your identity provider and syncs to Tailscale automatically. This integration ensures that your tailnet access control aligns with your organization's identity management processes. You can configure synced groups with your identity provider, including Google SSO integration.
\nThe synchronization typically occurs within minutes of changes in your identity provider. You can reference synced groups in policies using the group: prefix followed by the group name from your identity provider.
Tailscale offers built-in, dynamically generated groups called autogroups. These groups automatically include users with specific roles or properties. Autogroups remove the need to manually maintain groups for role-based access control.
\n![\"Tags](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftags.f874acf3.png&w=3840&q=75\")
Tags organize non-user devices like servers into functional groups for use in access control policies. Tags let you group devices by function, environment, or any other logical categorization. Unlike user-based groups, tags apply to devices and persist across authentication sessions.
\nThe tags table displays all defined tags with their owners. You can use the search field above the table to filter the results by tag name or owner.
\nBy default Owners, Admins, and Network admins are tag owners for all tags.properties.
\n![\"Create](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftags-add.046faa4b.png&w=1080&q=75\")
To add a tag using the visual editor:
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftags-edit.ea2a8518.png&w=1080&q=75\")
To edit a tag using the visual editor:
\n menu of the tag to edit, then select Edit.To delete a tag using the visual editor:
\n menu of the tag to delete.Deleting a tag removes it from all devices, potentially affecting access control rules that reference it.
\n![\"IP](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fip-sets.1f7cbbd7.png&w=3840&q=75\")
IP sets are collections of IP addresses, hosts, and subnets to use in access control policies. They improve policy management by letting you reference groups of network addresses with a single identifier. IP sets support composition, letting you build complex network definitions from simpler components.
\nIP sets support composition through Add and Remove operations. Start with broad inclusions using Add, then refine the set using Remove to exclude specific ranges. This approach lets you create flexible network segmentation without duplicating IP definitions.
\nFor example, you might add 10.0.0.0/8 to include your entire private network, then remove 10.0.1.0/24 to exclude a specific subnet. This composition model helps maintain complex policies as your infrastructure evolves.
![\"Create](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fip-sets-add.d86670f8.png&w=1080&q=75\")
To add an IP set using the visual editor:
\nTo edit an IP set using the visual editor:
\n menu of the IP set to edit, then select Edit.To delete an IP set using the visual editor:
\n menu of the IP set to delete.![\"Hosts](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhosts.e8dd63cb.png&w=3840&q=75\")
Hosts create friendly names for IP addresses and CIDR ranges. This improves policy readability by replacing numeric addresses with meaningful identifiers. Instead of remembering that 192.168.1.100 is your database server, you can reference it as database-primary throughout your policies.
You can use host definitions in access rules, IP sets, and other policy components that accept IP addresses. The hosts table displays all defined hosts with their associated IP addresses for quick reference. Host names make your policies self-documenting and reduce errors from mistyped IP addresses.
\n![\"Create](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhosts-add.ff04f4cf.png&w=1080&q=75\")
To add a host using the visual editor:
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhosts-edit.df464310.png&w=1080&q=75\")
To edit a host using the visual editor:
\n menu of the host to edit, then select Edit.To delete a host using the visual editor:
\n menu of the host to delete.![\"Node](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fnode-attributes.5cbdad3b.png&w=3840&q=75\")
Node attributes are device attributes and settings that you can use do things like control feature availability and device behavior across your tailnet. For example, you can use an attribute to enable Tailscale Funnel or configure specialized behaviors without modifying individual device configurations.
\nNode attributes commonly enable features that extend device capabilities. Understanding these common patterns helps you implement similar configurations for your specific needs.
\nThe funnel attribute lets devices use Tailscale Funnel for public access. The mullvad attribute grants access to Mullvad exit nodes for enhanced privacy. The drive:share and drive:access attributes enable Taildrive file sharing capabilities. The disable-ipv4 attribute disables IPv4 addressing for IPv6-only deployments.
Each attribute applies immediately to matching devices without requiring device reconfiguration or restart.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fnode-attribute-add.87801540.png&w=3840&q=75\")
To add a node attribute using the visual editor:
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fnode-attributes-edit.72cbd386.png&w=3840&q=75\")
To edit a node attribute using the visual editor:
\n menu of the node attribute to edit, then select Edit.To delete a node attribute using the visual editor:
\n menu of the node attribute to delete.![\"Device](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fdevice-posture.efd56960.png&w=3840&q=75\")
= 11.\">
Device posture rules define the requirements a device must meet for access control policies to prevent non-compliant devices from accessing sensitive resources. Posture rules can check for conditions like OS version, disk encryption status, and the presence of specific security software. You can create custom posture checks to enforce your organization's security policies.
\nPosture checks run continuously, revoking access if devices fall out of compliance.
\nYou can reference posture rules in the srcPosture field of access rules to enforce device compliance. Devices must meet all specified posture requirements to establish connections. Update posture definitions as security requirements evolve.
Posture enforcement happens at connection time and periodically during active connections. If a device falls out of compliance, existing connections end and new connections fail until the device meets requirements again.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fdevice-posture-add.744732a5.png&w=1080&q=75\")
To add a device posture rule using the visual editor:
\nnode:os, node:osVersion, node:tsAutoUpdate, node:tsReleaseTrack, node:tsStateEncrypted, node:tsVersion).For integration with enterprise device management systems, refer to the documentation for Intune, Jamf Pro, Iru (formerly Kandji), 1Password XAM (Kolide), and SentinelOne.
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fdevice-posture-edit.2744b47b.png&w=3840&q=75\")
To edit a device posture rule using the visual editor:
\n menu of the device posture rule to edit, then select Edit.To delete a device posture rule using the visual editor:
\n menu of the device posture rule to delete.![\"Auto](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fauto-approvers.f63dedcb.png&w=3840&q=75\")
Auto approvers are policies that let you automatically approve specific operations, such as advertising subnet routes or exit nodes, without manual intervention.
\nAutomatically approve subnet route advertisements from users, groups, and tags. This removes manual approval for subnet routers. Route auto approval lets you scale without administrative bottlenecks.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fauto-approvers-route-add.39c95d25.png&w=1080&q=75\")
To add a route auto approver using the visual editor:
\n192.0.2.0/24).To edit a subnet route auto approver using the visual editor:
\n menu of the subnet route approval to edit, then select Edit.To delete a subnet route auto approver using the visual editor:
\n menu of the subnet route approval to delete.Automatically approve users, groups, and tags as exit nodes. This lets designated devices route internet traffic without manual approval. Exit node auto approval supports use cases like regional exit nodes or dedicated privacy infrastructure.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fauto-approvers-exit-nodes-add.a4a0ebf8.png&w=1080&q=75\")
To add an exit node auto approver using the visual editor:
\nTo edit an exit node auto approver using the visual editor:
\n menu of the exit node to edit, then select Edit.To delete an exit node auto approver using the visual editor:
\n menu of the exit node to delete.![\"Tests](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftests.dbc3484d.png&w=3840&q=75\")
For an overview of tests and how they work in the visual policy editor, refer to the tests section in the visual policy editor documentation. This reference documents the UI controls and procedures for managing tests.
\nThe Tests tab contains sections for general access tests and SSH-specific tests. Tests act as regression protection, ensuring that policy modifications don't accidentally break existing access patterns.
\nCreate validation tests that access control changes must pass before saving. These tests ensure policy modifications don't accidentally revoke important permissions or expose critical systems. Well-designed tests catch configuration errors before they affect production access.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftests-general-add.ab075441.png&w=3840&q=75\")
To add a general test using the visual editor:
\n![\"Edit](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftests-general-edit.0bccc674.png&w=3840&q=75\")
To edit a general test using the visual editor:
\n menu of the test to edit, then select Edit.To delete a general test using the visual editor:
\n menu of the test.SSH tests let you write validation tests that Tailscale SSH policy changes must pass before you can save them. These tests verify SSH access rules work as intended. SSH tests validate both access permissions and authentication requirements. Tests run automatically when you save policy changes. Failed tests prevent the policy from saving and display error messages indicating which assertions failed.
\n![\"Add](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Ftests-ssh-add.294645ec.png&w=3840&q=75\")
To add an SSH test using the visual editor:
\nTo edit an SSH test using the visual editor:
\n menu of the test to edit, then select Edit.To delete an SSH test using the visual editor:
\n menu of the test to delete.Ask AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")