Access control
Tailscale Grants: make access decisions readable, testable and owned.
A Grant combines a source, an optional posture condition, a destination and an ip and/or app capability. A production-ready model also requires ownership for groups and tags, whole-policy allow/deny tests and an approved change path.
Principle
Allow only access explicitly named in policy.
The Grants rule model is deny by default: access is allowed only when it matches the complete published policy. However, a new tailnet's pre-created policy initially allows broad device-to-device connectivity, so it must be replaced and tested before it represents least privilege. Grants are recommended for new policies, while ACL syntax remains supported.
{
"src": ["group:ops"],
"srcPosture": ["posture:managed"],
"dst": ["tag:prod-web"],
"ip": ["tcp:22"]
}Four questions
- Who or what is the source?
- Which source-device conditions are required?
- Which resource can be accessed?
- Which network or application capability is allowed?
An app capability is opaque JSON to Tailscale. The destination application must read and enforce it; normal application authorisation remains a separate control.
Production readiness
Policy syntax alone is not enough.
Every group, tag, resource and exception needs a named owner and a removal process. Grants are additive: a narrow rule never overrides access allowed elsewhere.
Model
- groups, tags and privileged
tagOwners - resource-specific destinations
- posture and
ip/appcapabilities
Test the complete policy
- the intended connection is allowed
- the wrong user or device is denied
- the wrong destination and port are denied
Govern
- Git version control and review
- rationale and approver for each change
- controlled rollback to a validated policy version
AIM model
How Defense First uses Grants.
Advice designs the group, tag, posture and ownership model. Integrate implements the policy, tests and GitOps validation. Manage reviews and changes policy through the agreed pull-request and testing model.
