Hey,
I’m trying to have ZAC running on a different host than the controller and I don’t really want to use the same server certificate used for the controller edge-management (the one defined in web.identity on the controller’s config).
Is it possible to issue an identity for the ZAC, enroll it to get a server cert from the controller and use these to authenticate with the Management API ?
Any other way ?
First, you definitely don’t need to use the same server cert/key. The quickstarts do that just as an example of using TLS for ZAC. First, you need to place a certificate and key colocated to the ‘server.js’ file which you should find at the root of the directory. The files currently, must be named “server.key” and “server.chain.pem” due to how the code is currently written.
Next, the ZAC currently only works via username/password. There’s no way to configure the ZAC to use an identity from the controller to auth to the management API that I know of. I think we would need to implement that. Instead, what you can do, and what I’d recommend, is you can “split” the management API, create a service for ZAC, and then force ZAC to access the management API from that service.
I don’t have a good instructions or a good video on doing that, but I can outline it for you roughly here.
Open the controller’s config file and go to the bottom ‘web’ section. Notice that the first block of configuration is name, it’s an array and by default, it’s named “client-management”. Duplicate that entire block. In the original stanza, go down to apis and remove the edge-management and fabric binding sections (I will usually comment them out) and then rename the name to just be client… In the new block, rename it to be just management and then comment out the edge-client section in apis and change the bindPoint.interface/address to “some other port” like 18441 and importantly also change the interface from 0.0.0.0 to 127.0.0.1 so that the management interface is ONLY available from 127.0.0.1… You need to “be on the machine” in order to access it… Assuming you have a router located on the controller, you then make a service to offload the management api to 127.0.0.1 and you have secure access to the service… I hope that all makes enough sense, I bet it will for you… 
Here’s an example web config I just made as an example…
web:
- name: client
bindPoints:
- interface: 0.0.0.0:8441
address: ec2-3-134-108-218.us-east-2.compute.amazonaws.com:8441
identity:
ca: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ip-172-31-47-200-edge-controller-intermediate.cert"
key: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/keys/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-server.key"
server_cert: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-server.chain.pem"
cert: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-client.cert"
options:
idleTimeout: 5000ms #http timeouts, new
readTimeout: 5000ms
writeTimeout: 100000ms
minTLSVersion: TLS1.2
maxTLSVersion: TLS1.3
apis:
#- binding: edge-management
# options: { }
- binding: edge-client
options: { }
#- binding: fabric
# options: { }
- name: management
bindPoints:
- interface: 127.0.0.1:18441
address: 127.0.0.1:18441
identity:
ca: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ip-172-31-47-200-edge-controller-intermediate.cert"
key: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/keys/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-server.key"
server_cert: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-server.chain.pem"
cert: "/home/ubuntu/.ziti/quickstart/ip-172-31-47-200/pki/ip-172-31-47-200-edge-controller-intermediate/certs/ec2-3-134-108-218.us-east-2.compute.amazonaws.com-client.cert"
options:
idleTimeout: 5000ms #http timeouts, new
readTimeout: 5000ms
writeTimeout: 100000ms
minTLSVersion: TLS1.2
maxTLSVersion: TLS1.3
apis:
- binding: edge-management
options: { }
#- binding: edge-client
# options: { }
- binding: fabric
options: { }
Once you do that and restart the controller, you’ll see you can’t access the management API on 8441:
curl -sk https://localhost:8441/edge/management/v1
{"error":{"cause":{"code":"UNHANDLED","message":"path /edge/management/v1 was not found"}
But it will now be availalbe on localhost:127.0.0.1:18841:
curl -sk https://localhost:18441/edge/management/v1
{"data":{"apiVersions":{"edge":{"v1":{"apiBaseUrls"..... **etc**
Now I need to login to “localhost:18841” like this:
ziti edge login https://localhost:18441/edge/management/v1 -u $ZITI_USER -p $ZITI_PWD -y
Token: 6c606af3-9b64-49ba-a006-10df8c5da381
Saving identity 'default' to /home/ubuntu/.config/ziti/ziti-cli.json
Enabling a dark ZAC both in terms of accessing ZAC itself, as well as ZAC accessing ziti instances is on our todo list, we’ll get there some day but for now I think this would be a reasonable compromise.
Hope that helps?
And just for extra ‘proof’, let’s look at the listening ports using sudo and ss:
sudo ss -lntp | grep 8441
LISTEN 0 4096 127.0.0.1:18441 0.0.0.0:* users:(("ziti",pid=2468893,fd=9))
LISTEN 0 4096 *:8441 *:* users:(("ziti",pid=2468893,fd=10))
You can see ziti is now listening ONLY on 127.0.0.1:18841 and ${anyInterface}:8441
Hey, thanks alot for these explanations.
So I could have a let's encrypt certificate or any other self signed cert (not signed by Ziti) ? I mean, is this certificate only presented when someone's actually trying to reach ZAC or does the ZAC actually use it to authenticate with the overlay ?
So I guess this won't be achievable if I don't have an edge router on the same host as the controller ? Or is there any way to instruct Ziti to terminate traffic on the controller's node ?
ABSOLUTELY. You can even look at my playground ZAC (assuming I didn't tear it down when developing) here: https://zac.clint.demo.openziti.org:8443/
It's a "standard" server certificate. It's not used to authenticate to the overlay at all. In this example (above) I'm using LetsEncrypt certs.
Not at this time. We had a zitified ZAC a while back but it ended up causing some troubles and we had to "undo" that. It's definitely on our radar though. Just need to get back to "doing it". This does lead into a slightly more difficult topic of "on the same host"... So I'll go down that rabbit hole for a moment...
You do not need it on the same host, but, the ZAC needs to be able to address the controller's underlay endpoint (the management API). So you could 100% put it into the same VPC (amazon term for a private network) and then bind the management API to the 172.x.x.x IP (the internal IP for the VPS) and that'd work fine from the ZAC instance too. So it doesn't have to be "on the same host" but it'd need to be "in the same network" with this setup... So you could have one host as the controller, one for the edge router and one for ZAC and as long as ZAC can access the management API via the underlay, it'd be fine... Hopefully that's clear and makes sense?
That's great !
Alright, guess i'll stick with an edge router on the same VM as the controller
So to sum up it needs to be one of these scenarios :
I’d not put it quite that way.
I would say that IF the management API is not public. Whatever client is trying to use the management API (the ZAC or the ziti CLI) needs to be able to access the IP:port configured. You could absolutely do that via OpenZiti itself…
OpenZiti inception time… So, for example. I could run the ZAC on my LOCAL computer, if I provisioned an OpenZiti overlay service for ZAC…
Hope that makes sense??? EDIT: I reread your post and I think that second bullet actually covers what I outlined here. So yes those two bullets seem right to me
