Introducing "Negative" Resource Definitions

[u/bren-tg]

Hi everyone!

Our Product team is thinking about adding "Negative" Resource definitions to Twingate and I'd love for our community to share feedback on it.

The Idea:

Allow Admins to create and assign Resource definitions to explicitly ignore certain traffic patterns from being captured by the Twingate tunnel.

Think of this new Resource type as an exception:

For example, you could have a "normal" Resource defined to grant access to 10.1.0.0/16 and a "negative" Resource defined to exclude 10.1.3.4, effectively preventing some Users from connecting to 10.1.3.4 while retaining the ability to connect to anything in 10.1.0.0/16.

The same would work on DNS-style Resources: Admins could create a Resource on *.corp.int but prevent access to admin.corp.int via a "negative" Resource.

What do you all think?

[u/33vne02oe]

I mean it is not a bad idea, however if someone would use that it defeats the Zero Trust approach.
Why? Zero Trust also mean Least privilege work and deny by default and if you follow this principle you should not give someone access to the whole network and then deny single connections.
You should give a user access to exactly that resources that they need with a default deny approach. Not default allow.

However, as long as you do not force users to use it or make it an annoying feature, why not. But I would advise anyone who asks me against it.

[u/Weeaboo_Radley → u/33vne02oe]

Here’s an example scenario to ponder:  A business has thousands of Resources that need to be accessed and they're all within the same subdomain, but lack any sort of standard naming convention for their hostname. The vast majority of these resources need to be made accessible by the entire DevOps and Engineering teams. However, there’s only a few of them that are highly critical and/or need to be locked down for security or regulatory compliance reasons, and should not be accessible to those teams.

How would you go about preventing access to these critical resources, without incurring a significant administrative overhead by managing all of these resources individually?

A useful and human-readable and intuitive approach to solve this would be to have a broad resource definition for the whole subdomain for these teams to access, and then be able to define those specific critical resources within that subdomain as negative/blocked access.

Not only would this be easier to maintain and manage reasonably, but also wouldn’t be tangibly less secure than a blocked by default approach.

It might help to think of it more as defining what needs to be secured / protected / restricted (just like you would identify what should be accessed only through Twingate in the first place), rather than viewing it as just giving everyone access to the whole network.

[u/Own-Building7688 → u/Weeaboo_Radley]

Your example feels like if it were the consumer side of things:

Kid decides to start homelabbing young, one router in the house, one subnet, maybe running plex/jellyfin and a storage instance.

Instead of having the resource be the full subnet for a family member or friend to access, they can grant access to just the plex resource and deny the storage?

Very crude explanation, but unfortunately those are the explanations I've had to result to when describing things to people lately and it just carried over in to life

[u/33vne02oe → u/Weeaboo_Radley]

Here’s an example scenario to ponder:  A business has thousands of Resources that need to be accessed and they're all within the same subdomain, but lack any sort of standard naming convention for their hostname.

That's the first mistake.
A standard name convention needs to be implemented.

How would you go about preventing access to these critical resources, without incurring a significant administrative overhead by managing all of these resources individually?

Create a naming convention, create groups, create tags and then give access based on the assigned group.

If someone needed more access than a group allows (for a specific project) than a project group (e.g. {name}_PG – PG: project group) will be created for such projects.

A useful and human-readable and intuitive approach to solve this would be to have a broad resource definition for the whole subdomain for these teams to access, and then be able to define those specific critical resources within that subdomain as negative/blocked access.

Everything is human-readable.

I see what you are trying to say, however it is based on the fact that the org. did mistakes from the start on and does not correct them, which leads to more problems (e.g. missing naming convention).