firezone
Multi-site / Regional Resources
Multi-site Resources are resources you define once but exist in more than one network connectivity context (i.e. "Site")
One example would be a regional service you wish to expose to your work force, say an authoritative DNS service. This resource could be defined once, e.g. dns.company.com and then deployed regionally in each VPC you wish to serve as a point of presence (POP). You would only need to define this resource once in Firezone and attach a single access policy, but associate it to multiple Sites/Gateways.
- [ ] Expose "Add Multi-site Resource" feature flag
- [ ] #2801
- [ ] Document how multi-site resource routing works
- [ ] Manual site selection
- [ ] https://github.com/firezone/firezone/issues/6268
- [x] https://github.com/firezone/firezone/issues/5446
Notes from customer call:
They have the same DNS resources in both staging and prod. So there are in fact 2 resources with the same DNS address seen by customer in his client. Multi-site won't quite solve the problem here because we would need PAM at the site level, not Resource level in this case. In other words, the actual address to use would be solved by Unlocking the prod site, prioritizing it for routing over the staging site. refs #6158
They have the same DNS resources in both staging and prod.
Does the DNS address resolve to the same IPs in both cases?
They have the same DNS resources in both staging and prod.
Does the DNS address resolve to the same IPs in both cases?
Yes, they also have CIDR resources corresponding to prod/staging that are numbered the same. This seems to be quite common for staging and prod if the customer is following the "make staging exactly like prod" ideology.
I think this pretty much works, just need to iron out any connlib edge cases.
Thinking more about this, I'm not sure we specifically need Resources to live in multiple Sites. Instead, a site can contain Gateways in multiple physical locations, and the portal will load balance across them.
When creating a Site, we can prompt the administrator to select what "type" of site it is:
- Regional
- Global
Is there any difference in how we route packets to regional vs global sites?
Is there any difference in how we route packets to regional vs global sites?
Not today. I think this would mostly be for UX, and/or opening the possibility for different routing options in the future. Besides the current geographical one, users have expressed in having the ability to manually select which gateway (or I guess... "Site") to egress from.
That would actually be one reason to keep multi-site resources here, because then we can model the site selection configuration as a policy condition.
Besides the current geographical one, users have expressed in having the ability to manually select which gateway (or I guess... "Site") to egress from.
I think we need to dig deeper on this. Gateways within a site should be interchangable otherwise load-balancing won't work, right?
I am all for challenging the model but I don't see the case for multi-site resource yet:
- In the whole staging vs prod thing, they are IMO different resources.
- If it is truly the same resource, i.e. it can be reached from two or more sites, then the sites are too granualar and should be merged.
I think a "private site" could also be a useful term for anything that contains private networks? Other than SWGs and full-tunnel, what are use-cases for a site that routes to the Internet (i.e. global?)
Hm, how can we support the use case of letting the user decide which Site to connect to for a particular Resource (i.e. the Internet resource, or any globally-deployed SaaS app).
Hm, how can we support the use case of letting the user decide which Site to connect to for a particular Resource (i.e. the Internet resource, or any globally-deployed SaaS app).
What are they trying to achieve with that selection?
If there is a globally-deployed SaaS app, why is it accessible via different sites? If it is only one site, why does it matter which Gateway they go through?
At present, sites are pretty transparent for the end-user which I think is a good thing. In the end, they are trying to connect to resources, not sites.
The point I do see is:
- A given CIDR (or domain) may be identical between prod and staging.
- Users may want to switch between the two of them.
- So maybe, the existing grouping of resources into sites could be used as a way to deal with overlapping resources: Users would activate or deactivate entire sites. Maybe we could even offer a way to fork or mirror a site in the portal in order to keep it in sync. Or offer something like site-templates?
The use case given by the customer was for the internet resource -- sometimes their workforce needs to egress out of the EU, sometimes the US. Ideally they want the ability for their workforce to select the egress network (competitors do this)
Ah interesting! That makes sense. Thanks for sharing.
I wonder if we can make the Internet site special here and introduce regions just for that one before adding it to all sites.