Say I had a management network that I make dark. In this management network are UPS’s, VMware hosts and virtual centre, backup servers, but could really be anything. These services are only required by a select few and should be hidden off the network. Currently these would/should be behind a jump server. Using Ziti would relegate the jump server to a standby back door to be turned on when needed.
Whether it is a subnet ziti network or a ZTHA is a mute point for this discussion.
When it is zitified, then those services are available wherever in the world someone happens to be. They could be across the other side of the world, and yet still access virtual centre of VMware, or that UPS.
My question, is can you limit the locations that can be used to access those services. Kinda like a posture check. There is no IP check posture check available, and it would have to be based on the IPv4 public side, and not the LAN side address as multiple locations could use the same LAN address scheme.
I thought about putting in a ZET that is only available within the local network, but a ZET needs to talk to a (public) edge router which would then open it to the whole world again?
Just wondering if anyone has asked this question before? I gather there may be some agencies that may request this to limit access to some backend systems?
Limit access to the controller and edge router to only the building… (i.e. its only accessible via closed network off the grid… which means that the controller and edge router will not have access to the internet)
I believe this will work… however… it will not be able to support access outside the building
By way of example, consider the Docker implementation… as the container is not accessible to the internet…
well at least I think this is correct… as I have never found a way to tunnel into the docker container to access it remotely … though I could be wrong
The larger question then is… if its needs such tight security… why would you open it up to the internet… which goes back to the situation you are faced with.
I want to have it both ways - both internal and external services, However that would be one way of doing it. Two setups, with two identities for ‘the chosen ones’ - one limited to internal only accessible services, and one for external accessible services.
My ziti implementation is dockerized and public facing. The controller and edge router are all dockerized on my host. I bind the ports of the containers to the host, and then open a VIP, or a mapping from the internet to the port on the host running the docker instances.
You can deploy private routers with edge that listens on the private IP within that site. All ZTAA and ZTHA endpoints in this site can be limited to just dial and bind services through those routers for internal and external services. I think that should be close to what you are trying to achieve.
If I can restate, I think you want to provide zero trust access to these extra secure resources, but you only want people who are physically somewhere to have access to the extra secure services. Presumably, that would represent an increased security posture because they are physically in some building, is that the case? Sounds like the idea here is that this adds another layer of claims to the connection.
Two Identities - Two Networks
@markamind’s solution can get you what you want. You’d have two openziti installs and two identities for users, the ‘regular’ identity and this ‘extra private’ one. That might be ok.
Private Router - Two Identities
@dariuszSki puts a neat bit of a spin on it (assuming I understand) and I think it would work, might be worth trying. You’d still need two identities but you’d only need to run/manage a single network. You’d make a private edge router and then an edge router policy for edge routers “on net” so that only when “on net” could they connect to that private edge router. Then you use regular controls to restrict these identities from getting onto the network by any other router. They must only access the network from the private router.
The only risk is that if you ever screw your router policies and allow these “extra secure” identities access any edge router, you’d allow access from ‘anywhere’ like you were worried about. To mitigate that, I think you could setup those edge routers in that private network without the link dialers configured so they are actually not “part of the mesh” and they would not form a connection outbound to the rest of the fabric.
And, now that I think about it. With that setup, you might be able to get away with having only one identity then… @dariuszSki does that last part make sense, that’d work I’d think, right (two routers, the private router forming no links and only being ‘edge’ enabled)? That would look like this:
@TheLumberjack Yes and no, the last diagram is almost complete, but the private router will always try to create the fabric link(s) if there is a public router available. You cant disable the fabric dialing as far as I know. That is ok I would think even in this use case if I understand it correctly. If I were to do this, I would most likely limit all communications in and out of that site through the private routers for all identities located in that site that are not mobile, i.e. cant leave the site and therefore don’t need access to the public routers.
@TheLumberjack Ok, I doubled check the config and I missed to comment out the dialer line as well. Once I did that, the router stays up. Cool! Was this always like that? I could have sworn that you needed that at some point.
I know I’ve never tried this particular setup before, so I don’t know if that’s always been a thing or not I’m gonna test some things here too. A service edge router policy might be another approach too. I’ll do some testing - my interest is piqued
Ok. I did some testing. This can also be accomplished with a single identity and by refining/adding/changing service-edge-router-policies. This is probably going to be a long post so get some refreshments and settle in…
I have a network that I deployed the quickstart into I use for testing. This network has the setup as shown above. There’s a public router deployed into a cloud provider, and a private router deployed on my home network. Those are the two routers pictured above (public/private).
This network was deployed using the quickstart. That means I have a service-edge-router-policy preconfigured for me which is #all/#all (all services can innitiate or terminate on all routers).
I have three different identities, two dialers and one to bind the service
one identity, dialUser1, is on this computer I’m typing on (my identity) and I’m sitting in my home right now so I’m on “the private network”.
the other identity, dialUser2, is running on the edge router out in cloud provider, emulating an identity NOT on “the private network”.
the last identity is the identity that will Bind the service
First thing I had to do was delete the allSvcPublicRouters service-edge-router-policy. Once deleted, no services will work since services can’t initiate or terminate on any routers at that point. (use policy-advisor to figure this stuff out)
tested and verified that dialUser2 (remember, they are not on the local network) cannot access the service. this user receives timeouts and a log message indicating: “connect timeout: no suitable edge router”
So that looks like what you want and need - you’re read to move past the default Service Edge Router Policy all/all. Just be careful… it’s really easy to mess these things up! I am sure you’ll have no issues trying it out.