Handle conflicting traffic restrictions for users who have access to Resources with overlapping addresses about firezone HOT 6 OPEN

cc @conectado @bmanifold @AndrewDryga

This is going to need a fix before we roll out #4743 I think... wondering if this is the easiest way to solve the issue.

Trying to avoid making the user create a Resource for all combinations of ports/protocols they want to limit for each Group, which is the current way you can solve the issue now.

from firezone.

Maybe the simpler approach is to move the traffic_filters to policies instead, since that is where the admin is linking a Group to a Resource, and they can define which traffic is allowed for the particular Group at the time of policy creation.

from firezone.

I think the use case here is weird, what you should do is define two resources:

• gitlab.company.com:80,443 with access to everyone
• gitlab.company.com:22 with access to devops

Then the client/gateway must differentiate between those two, if they do not - it's a bug. Plus there are many other reasons why two separate ports on the same hosts can have different resources. Moving this to policy is trying to hide the problem without solving it.

from firezone.

@AndrewDryga That won't work. DNS resolution doesn't take ports into account, so when a user who has access to both resolves the name, the client won't know which one is the one to use until traffic flows, at which point it's too late.

The other option is to send all traffic restrictions from the portal down to a gateway for a all Resources with the same address that the user has access to. I.e. to authorize based on address and not ResourceId.

We would need major changes to the way DNS is resolved and mappings handled to pick the right set of traffic filters to use.

I'm not seeing a better approach that won't require onerous refactoring?

from firezone.

Hm yeah, actually -- adding this to Policies won't solve the issue because the wrong policy could still be used to resolve access to the Resource.

For example, the Everyone policy granting access to the tcp/443 Resource could still be picked for the DevOps user who's trying to access tcp/22.

Need to think through this more. This means that Everyone policies can cause issues when tied to Resources with overlapping addresses, since there isn't a way to remove a Group from a policy definition.

from firezone.

Based on the above it seems that the fix here to have the client select all Resources that match a particular address seen, and use all of them in the allow access request.

The portal would then need to resolve all policies for the matched Resources and send them all down to Gateway, coalescing the traffic restrictions for that particular Peer.

from firezone.