![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: May 29, 2025
\nGrants are Tailscale's enhanced access control system that combines network layer and application layer permissions into a unified framework. Grants let you precisely define what resources each user or device can access and which actions they can perform after connecting. They follow Tailscale's deny-by-default approach, aligned with zero trust and least privilege principles.
\nGrants can do everything ACLs can, plus they facilitate application-level permissions and route filtering. Refer to grants vs. ACLs.
\nReady to get started? Check out the get started guide or, if you've been using ACLs, the migration guide.
\nGrants offer significant advantages over traditional access control methods by unifying network and application permissions in a single system. This consolidated approach reduces complexity and provides a more consistent security model across your entire tailnet. With grants, you can:
\nvia.Explore the collection of example grants for common use cases.
\nGrants operate on a principle of explicitly defining which users or devices (sources) have access to which resources (destinations) along with what capabilities they have after connecting. Each grant consists of three core components:
\nip field) and application capabilities (the app field).When working with grants, you'll operate at two distinct layers: the network layer and the application layer. The network layer refers to IP addresses, ports, and protocols for connections between devices. The application layer refers to capabilities within applications themselves, such as which specific features or data sources a user can access. This dual-layer approach enables more comprehensive access control than network-only permissions.
\nEach grant uses the grant syntax with a source (src), a destination (dst), and at least one type of permissions: network permissions (ip) or application permissions (app). You can extend this basic structure with additional options including device posture checks (srcPosture) and routing specifications (via).
Sources (src) and destinations (dst) define who can access what in your tailnet. Both fields accept a wide range of selectors that identify users, devices, groups, or IP address ranges.
You can specify sources using selectors like:
\nname@example.com) for individual users.group:engineering) for user groups.tag:database) for device groups.autogroup:admin) for administrative users.Similarly, you can define destinations using the same types of selectors, plus special selectors like autogroup:internet and svc:web-server (for Tailscale Services).
Refer to the grants syntax reference for more information.
\nNetwork capabilities control basic connectivity between devices in your tailnet. These permissions define whether devices can establish connections and what protocols and ports they can use.
\nThe ip field in a grant specifies network layer capabilities, allowing you to define access at the protocol and port level. You can grant access to specific ports, port ranges, or entire protocols. For example, \"ip\": [\"tcp:443\", \"udp:53\"] grants access to TCP port 443 (HTTPS) and UDP port 53 (DNS) on the destination.
Refer to the grants syntax reference for more information.
\nApplication layer capabilities go beyond basic connectivity to define what actions you permit after a device establishes a connection. Applications running on the destination device can read these capabilities from requests made over the tailnet to authenticate and authorize the requester. These capabilities allow for fine-grained control over feature access within applications, similar to role-based access control systems.
\nThe app field specifies application layer capabilities in the format \"domainName/capabilityName\". For example, \"tailscale.com/cap/tailsql\" identifies capabilities for the TailSQL application. Each capability can include parameters that define specific permissions, such as which data sources the device can access or what operations to permit. This approach extends zero trust principles to the application layer, enforcing the principle of least privilege for connected applications.
Refer to the grants syntax reference for more information.
\nWhile grants provide powerful access control capabilities, there are some important considerations to keep in mind:
\nsrc) of a grant, not to the destination (dst).For more information, refer to grants limitations and considerations.
\nNot sure what to do next? Consider the following possibilities:
\nvia.Ask AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}