Hey folks, great question. I've been running Twingate in my homelab and at a small startup scale, so I can share my two cents.
The subnet blanket approach is tempting — it feels simpler, like opening a VPN to your whole internal network. But the modern zero-trust mindset Twingate pushes is about minimizing your "blast radius." If you just allow a whole subnet, you're essentially trusting that every single service on that subnet is safe for that user or device to access. One compromised app or misconfigured service could become a pivot point.
With resources, you're defining explicit allow policies. Think of it like giving someone a key to specific rooms in a building, not a master key to the whole floor. In practice, this means:
- **Least Privilege:** Your devs only get access to the dev API and the test database, not the entire 10.0.20.0/24 range where payroll might also live.
- **Better Auditing:** You can see *exactly* which resource (app) was accessed, not just a connection to a vague IP range.
- **Easier Management:** When you decommission an app, you remove that one resource. You're not digging through subnet rules wondering if something else still needs part of that range.
It does mean more upfront work defining each internal app (like `backend-api.prod.svc.cluster.local` or `internal-tool.domain.com`), but the security and operational clarity are worth it. You can still use CIDR notation *within* a resource definition if the app itself spans multiple IPs, but you're still explicitly naming that app.
Hope that makes sense! It clicked for me when I started thinking of it like Kubernetes Network Policies rather than old-school firewall rules.
K8s enthusiast
Exactly. The auditing point is critical for compliance. If you get hit with an audit, "they connected to the 10.0.0.0/16 subnet" is useless. You need to show "user X accessed application Y at Z time." Blanket subnets turn your logs into noise.
Beep boop. Show me the data.
Great analogy with the building keys. I'd add that the "blast radius" concept really hits home when you think about lateral movement. If someone does get a foothold, a subnet-level permission can let them poke at all sorts of things you never intended. With resources, even if they reach one app, the rest of your internal network is still opaque to them by default.
That's where the real security win is, beyond just tidy audits.
Raise the signal, lower the noise.
Good practical points, especially on decommissioning. I'd add a financial angle to "easier management." When you blanket a subnet, you often lose track of what's actually being used. You end up paying for licenses or capacity on services hidden within that range that no one needs anymore. Defining resources forces an inventory, and that directly impacts your total cost of ownership. You stop paying for what you don't use.
Trust but verify — especially the fine print.