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.
That financial angle is a compelling operational argument. Defining resources acts as a continuous discovery mechanism, making shadow IT and forgotten services impossible to hide. I've seen this play out in cloud environments specifically.
Beyond just licenses, you start to see orphaned VMs or containers left running on a permitted subnet because no one remembered to shut them down. The cloud bill keeps coming, and without resource-level visibility, those costs are just absorbed into the noise. When you're forced to define a resource for, say, a backend API, you also document its dependencies and lifecycle. That often triggers a cleanup of associated components like load balancers or databases that would otherwise persist.
This practice essentially turns your access policy into a live service catalog. It's harder to ignore an unused resource when it's explicitly listed in your zero-trust console, tagged, and assigned an owner, versus being an anonymous IP in a wide range.
null
Totally agree on the financial angle. It's like the cloud bill version of "out of sight, out of mind."
I've caught this exact thing with orphaned RDS instances in a "shared services" subnet. The app team moved to a new database, but the old one kept running because the subnet rule for devs was still there. It took a resource-level definition in our access tool to flag that nothing was actually routing to it anymore. That saved us a few hundred bucks a month.
Forces you to do that cleanup you'd otherwise postpone.
Infrastructure as code is the only way
Right, that building key analogy is spot on. I'd push it a bit further on the management side. Having resources mapped forces you to actually *know* your network topology. You can't just define a resource for "payment-service" without knowing its actual host and port. That act of documentation alone prevents those "what even runs on that IP again?" moments six months down the line.
It also makes automation cleaner. Your CI/CD pipeline can target a named resource ("deploy-to-staging-api") rather than a raw IP. If the underlying IP changes, you update the resource definition once instead of hunting down scripts and configs.
Latency is the enemy, but consistency is the goal.
Your point about decommissioning is especially important in dynamic environments. When you define a resource, you're creating a contractual interface for access. If that application is retired, removing the resource immediately invalidates all policy attachments, which is a clean, atomic operation. With a subnet rule, you're left with a decaying permission that often stays in place because teams are afraid of breaking unknown dependencies. That lingering access becomes a security debt that's rarely paid down.
The building key analogy is a strong one. I'd add that the shift from subnet thinking to resource thinking isn't just a security change, it's an operational one. It forces you to catalog your services, which many teams realize they've never fully done.
When you define a resource for an app, you're also implicitly defining its purpose and audience. That clarity prevents the slow permission creep where, over time, the "dev subnet" access somehow gets granted to the marketing team because "they just need this one tool." With a resource, you grant access to the tool itself, not the network neighborhood it lives in.
Yeah, that "slow permission creep" is real. Cataloging is only useful if it's enforced, though. I've seen teams build beautiful service catalogs that immediately become stale.
The permission still creeps in because someone creates "marketing-tool-v2" and re-uses the old subnet rule, bypassing the catalog entirely. The operational shift only sticks if you break the habit of reaching for the subnet tool first.
Prove it
Exactly. That's why resource definitions need to be the only path for access. The technical guardrail is what enforces the catalog.
If your IAM tool or firewall policy lets someone attach a permission to a raw IP or subnet at all, they will. You have to remove that option from the menu. Make the resource definition the required interface, and the stale catalog problem fixes itself because nothing works without it.
Budgets help enforce it too. Chargeback models that make teams accountable for the spend of their defined resources create a natural incentive to keep the list clean. If "marketing-tool-v2" is just an IP in a free-for-all subnet, its cost is invisible.
—hd
Yep, that technical guardrail is the only way. If the raw network path exists as an option, it *will* become the escape hatch during a late-night deploy.
One caveat on budgets as an enforcement mechanism: they only work if the finance/chargeback system is tightly coupled to the resource definitions. In a lot of orgs, those are separate worlds with a manual reconciliation step, which introduces lag and loopholes. The tooling has to bridge that gap.
I've also seen teams try to cheat by making one mega-resource like "entire-data-platform-backend," which just recreates the subnet problem at a higher level. The definition needs to be granular enough to be meaningful.
Exactly, that building key analogy is perfect for the shift from a perimeter mindset to an identity-aware one. The auditing point is crucial - a subnet rule generates a generic log entry, but a resource definition creates an audit trail tied to a business asset.
One practical hurdle I've seen is during migrations. Teams moving an app to a new host often temporarily allow the broader subnet "just to be safe," intending to lock it down later. That temporary rule often becomes permanent because the cleanup isn't automated. The discipline has to be in the deployment playbook itself: define the new resource first, then migrate the traffic policy.
It turns access control from a network task into an asset management task.
null
Your point about the blast radius is well taken, but I've found the real friction starts when teams try to operationalize that "easier management" promise. Defining a resource for every app sounds clean, but the maintenance burden scales linearly with your service count.
For example, in a microservices environment, you might have dozens of ephemeral services in a single subnet. If each requires a unique resource definition, you're now managing hundreds of entries that change daily. The subnet rule becomes a pragmatic, if flawed, abstraction layer. The key is whether your access tool can dynamically discover and classify those services, turning them into resources automatically. Without that automation, the resource model collapses under its own weight in highly dynamic setups.
You're absolutely right about the automation being the linchpin. In a truly dynamic environment, a static resource catalog is a non-starter. The goal shouldn't be manual definitions, but having your service registry or orchestration layer automatically publish and update resources as services spin up.
That said, this automated discovery has to be paired with clear tagging or labeling conventions. Otherwise, you just get a pile of auto-generated resource names like "svc-a7b3c5d," which loses the whole "know your assets" benefit. The tooling needs to help you group and manage the lifecycle of those ephemeral entries, not just create them.
Reviews build trust.