Tailscale ACL Policy Standards

Intermediate

Enforce zero-trust ACL policy standards — deny-by-default, tag requirements, group-based access, port specificity, and mandatory ACL testing before deployment.

File Patterns

**/tailscale/**/*.json**/tailscale/**/*.hujson

This rule applies to files matching the patterns above.

Rule Content

rule-content.md

# Tailscale ACL Policy Standards

## Rule
All Tailscale ACL policies MUST follow zero-trust principles. Deny by default, allow specific access only. All devices MUST be tagged. All ACL changes MUST include tests.

## Format
```json
{
  "groups": { ... },
  "tagOwners": { ... },
  "acls": [ ... ],
  "ssh": [ ... ],
  "tests": [ ... ]
}
```

## Requirements

### Groups
- Define groups for every team or role
- Use email addresses, not usernames
- Keep groups aligned with SSO/IdP groups

### Tags
- ALL servers MUST be tagged (tag:server, tag:production, tag:staging)
- ALL CI/CD devices MUST be tagged (tag:ci)
- Tag names use kebab-case: tag:web-server, tag:database

### ACL Rules
```json
// GOOD: Specific ports, tagged destinations
{ "action": "accept", "src": ["group:engineering"], "dst": ["tag:staging:443,3000"] }

// BAD: Wildcard everything
{ "action": "accept", "src": ["*"], "dst": ["*:*"] }
```

### Mandatory Tests
```json
{
  "tests": [
    { "src": "dev@company.com", "accept": ["tag:staging:443"], "deny": ["tag:production:443"] },
    { "src": "tag:ci", "accept": ["tag:staging:22"], "deny": ["tag:production:*"] },
    { "src": "ops@company.com", "accept": ["tag:production:22,443"] }
  ]
}
```

## Rules
1. NEVER use `"*"` in src or `"*:*"` in dst
2. ALL devices MUST have at least one tag
3. Use port-specific rules (not wildcard ports) unless justified
4. ALL ACL changes MUST include corresponding tests
5. Review ACLs quarterly for stale rules
6. Use autoApprovers for automated infrastructure only

## Examples

### Good
- Engineering accesses staging on ports 443 and 3000 only
- Ops accesses production with specific port rules
- CI tagged and limited to deployment ports
- Tests verify both allow and deny cases

### Bad
- `"*:*"` allowing all traffic (no zero trust)
- Untagged devices (cannot manage at scale)
- No tests (changes break access silently)
- Wildcard ports when specific ports are known

## Enforcement
ACL changes must be reviewed by security team.
Tests must pass before applying changes.
Quarterly ACL audit with team leads.

FAQ

Discussion

Loading comments...

# Tailscale ACL Policy Standards ## Rule All Tailscale ACL policies MUST follow zero-trust principles. Deny by default, allow specific access only. All devices MUST be tagged. All ACL changes MUST include tests. ## Format ```json { "groups": { ... }, "tagOwners": { ... }, "acls": [ ... ], "ssh": [ ... ], "tests": [ ... ] } ``` ## Requirements ### Groups - Define groups for every team or role - Use email addresses, not usernames - Keep groups aligned with SSO/IdP groups ### Tags - ALL servers MUST be tagged (tag:server, tag:production, tag:staging) - ALL CI/CD devices MUST be tagged (tag:ci) - Tag names use kebab-case: tag:web-server, tag:database ### ACL Rules ```json // GOOD: Specific ports, tagged destinations { "action": "accept", "src": ["group:engineering"], "dst": ["tag:staging:443,3000"] } // BAD: Wildcard everything { "action": "accept", "src": ["*"], "dst": ["*:*"] } ``` ### Mandatory Tests ```json { "tests": [ { "src": "dev@company.com", "accept": ["tag:staging:443"], "deny": ["tag:production:443"] }, { "src": "tag:ci", "accept": ["tag:staging:22"], "deny": ["tag:production:*"] }, { "src": "ops@company.com", "accept": ["tag:production:22,443"] } ] } ``` ## Rules 1. NEVER use `"*"` in src or `"*:*"` in dst 2. ALL devices MUST have at least one tag 3. Use port-specific rules (not wildcard ports) unless justified 4. ALL ACL changes MUST include corresponding tests 5. Review ACLs quarterly for stale rules 6. Use autoApprovers for automated infrastructure only ## Examples ### Good - Engineering accesses staging on ports 443 and 3000 only - Ops accesses production with specific port rules - CI tagged and limited to deployment ports - Tests verify both allow and deny cases ### Bad - `"*:*"` allowing all traffic (no zero trust) - Untagged devices (cannot manage at scale) - No tests (changes break access silently) - Wildcard ports when specific ports are known ## Enforcement ACL changes must be reviewed by security team. Tests must pass before applying changes. Quarterly ACL audit with team leads.