Handle conflicting traffic restrictions for users who have access to Resources with overlapping addresses

[jamilbk]

Problem:

• DevOps needs access to SSH and HTTPS on gitlab.company.com
• Everyone needs access only to HTTPS on gitlab.company.com

Defining two Resources with a TCP/22 traffic restriction and TCP/443 restriction respectively would cause an issue because the Client/portal might pick the HTTPS resource instead for DevOps users.

There isn't an easy way to solve this. We need to send the Resource's address to the Portal from the client instead of the ResourceId, and let the portal find all matching Policies to send to the Gateway for access, so that the Gateway can coalesce the traffic restrictions properly.

[jamilbk]

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.

[jamilbk]

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.

[AndrewDryga]

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.

[jamilbk]

@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?

[jamilbk]

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.

[jamilbk]

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.