Hi All,
The last week, I tested everything Open Ziti has to offer. I created my first network, zitified Python and C application, lan-gateways with the tunneler and the Router. I also tested Cloud-to-Cloud connectivity and several approaches from the network side.
I do understand the idea, and honestly I like it a lot. Also, the DNS part seems to be a game changer in the network world.
I really like this technology!
But I have one problem which does impact the implementation a lot.
From a client/implementer perspective, one thing is missing from my point of view. To generate, a full-blown ZeroTrust overlay network, you need a lot of time, effort, and processes in place to get it working. You require server-, client-, SRE-, and developer teams working together how to approach and implement this solution based on their needs. Most of the time, this will can't be done from the ground up. It's a large, quite big project which can run a year or longer (depending on size).
During the time of creation, you need to start with the location and or VLANs/Vnets/VPCs with LAN-gateways. Other options seem not executable, as you would need to have one "Big-Bang" implementation, where everything needs to be zero-trust, up and running from Go-Live onwards.
This is not an option at all for a medium to big sized company.
Problem Description (hypothetical):
I tested this approach with the LAN Gateways based on router level. I played a lot with the configs and DNS settings, everything seems fine but one thing. If I have ONE router installed, let's say at a location. There are multiple VLANS:
- Vlan1: Guest Network --> Should have no OpenZiti Connection
- Vlan2: Office Network --> should have access from Identity SideA.Office.Clients
- Vlan3: Operation IT (some IoT Devices) --> should have access from Identity SideA.IoT.Devices
For now everyone would have, per the guides available, one single Identity/attribute. That would be a devastating approach to network security. Everyone who has access to the IP of the router would be able to use this Identity.
This is even a bigger problem if we talk about Cloud or Multi Cloud environments!
YES, you could limit the access to the Router Host by Firewall installed at the location or cloud environment. Which doubles the amount of devices, efforts to maintain and cost of ownership per location.
YES, the Host has its own firewall (ufw) to not double costs.
BUT: You are still limited to use one Identity for IoT and User Devices which, again, would be a network security problem.
Possible Solutions and drawbacks:
-
Create "Top-Rack" routers for every VLAN. Every router can have their own Identity and can be located across networks to be only reachable from the destined subnet either by central firewall or host firewall.
Positive: Every LAN will have their own identity.
Drawback: every LAN needs their own router either virtual or hardware provided which will skyrocket costs and maintenance. -
Use a zitified Caddy reverse proxy with the client_ip filter (not tested yet). Hypothetically, you would be able to install/bind your Identities to a zitified Caddy reverse proxy. The idea is to use something like the following. I do not know if multiple bindings are working and if the caddy file is correct, but that's what I'm currently investigating to solve this problem.
Positive: Based on the Match of the client IP, the right identity is chosen and routed through the overlay network. This can be achieved, if caddy reverse-proxy can handle multiple identities, via one instance only. would separate the ZeroTrust-network from the "source-desider"
Drawback: Second maintenance and upgrade costs at every router level and different management. The larger the network, the larger the maintenance effort. If the Host is corrupted, the Identities could be modified, which would create a whole in the authentication process.
Idea of Caddy file:
{
admin off
http_port 8080
}
localhost:8080
@Vnet1 {
client_ip 192.168.1.0/25
expression Vnet1('192.168.0/25')
}
@Vnet2 {
client_ip 192.168.128/25
expression Vnet2('192.168.128/25')
}
reverse_proxy @Vlan1 {
# intercept address, will be used if service id not set in the 'ziti' block
transport ziti {
# required, ziti identity file
identity {$ZITI_IDENTITY_Vnet1}
}
}
reverse_proxy @Vlan2 {
# intercept address, will be used if service id not set in the 'ziti' block
transport ziti {
# required, ziti identity file
identity {$ZITI_IDENTITY_Vnet2}
}
}
@denied not client_ip Vnet1 Vnet2
abort @denied
- Ziti Option:
Favorite solution:
A matcher-config within the intercept at OpenZiti Level. The Intercept is only hit/recognized if the source IP matches the network configured. This would keep things clean and simple from the start. So I can create, let's say, transit services.
Let me know what you are thinking about that and if there are already solutions or roadmaps planned to that.
Thanks all!
