I've been working with several clients to standardize their Tailscale setups for three-tier web applications (presentation, application, and database layers). While the automatic ACLs are great for getting started, I've found that explicitly defining a policy for this pattern improves auditability and prevents scope creep as teams grow.
Here's the core policy I've been iterating on. The goal is to segment each tier while allowing necessary east-west traffic and providing secure admin access.
**ACL Policy Overview:**
* **Tag Declaration:** Each server type is tagged (`tag:presentation`, `tag:application`, `tag:database`). Human users are grouped by function (`tag:frontend-devs`, `tag:admin-ops`).
* **Tier Isolation:** The `application` tier can only be initiated from the `presentation` tier, and the `database` tier only from the `application` tier. Direct access to the database from presentation servers or most users is blocked.
* **Admin Override:** A small `admin-ops` group can reach all tiers for emergencies, but daily development work uses the standard flow.
**Key Sections from the ACL:**
```
// Grant access from presentation tier to application tier
{
"src": ["tag:presentation"],
"dst": ["tag:application:*"],
"proto": "tcp",
"ports": [3000, 8080] // Your app ports
},
// Grant access from application tier to database tier
{
"src": ["tag:application"],
"dst": ["tag:database:*"],
"proto": "tcp",
"ports": [5432, 6379] // Postgres, Redis
},
// Restrict database tier from initiating connections
{
"src": ["tag:database"],
"dst": ["*:*"],
"proto": "icmp", // Only allow pings for health checks
},
// Admin bypass (strictly controlled)
{
"src": ["group:admin-ops"],
"dst": ["tag:*:*"],
},
```
I'm curious how others have approached this. Have you found a need for more granular rules, like logging denied connection attempts? Does anyone manage similar policies at a larger scale (dozens of nodes per tier), and if so, how do you handle the maintainability of the ACL file?