I have seen prior posts about securing the controller and the ZAC. All that is great info, but outside the scope of my use case. I am looking for the MVP of securing the controller. Think old-school, not opening ports I don’t need to, only ssh into the host or tunneling some ports to access the UI.
What if I…
Only opened the port (which one?) on the controller required for identities and routers to enroll and communicate?
Only accessed the controller from the actual host?
Only ran the ZAC on the actual host but didn’t expose any of the ports?
Would that suffice as a first iteration of protecting the controller?
Hey again @jptechnical ! The bare miniminum surface area for the Ziti controller is to expose the ctrl plane and the client API. The ctrl plane server listener TCP port is configured in property ctrl.listener. The port for the client API is the port of the web listener to which you “bind” the client API.
Client API binding example:
web:
- name: client-api
bindPoints:
- interface:0.0.0.0:1280 # the config for this web/api listener
address: my-ziti-clients.example.com # the address advertised for this listener's bindings
apis:
- binding: edge-client # a list of one bindinging on this listener, the client API
In this example, only the client API is bound to the web listener. You will probably want to also bind the management API binding: edge-management, but it doesn’t have to be the same listener! We recommend “splitting” those two APIs, i.e., binding them to separate listeners. That way you can control network access to the management API separately.
1 Like
Excellent! I assumed this was the case. It’s good to know that the client API is the only thing that must be public. I can definitely get around the access to the control plane API… that’s easy enough… the clarification gives me all the direction I need.
So, how does the ziti service listening on that port get patched? Is a docker pull sufficient to get the latest release (quickstart in my example)? Where are notices for any CVEs or releases announced?
Finally, for me second iteration, is there any recommendation to put it behind a WAF? Is there any further securing of the client API that can/should be done?
how does the ziti service listening on that port get patched?
You're running the openziti/quickstart container image. That container image is published when an administrator manually triggers this CI job which runs this shell script. A quick read of the script shows that it will always overwrite container image tags :latest and the semver tag for the latest Ziti release. You may want to pin the SHA256 of the image to control updates. I believe one of the admins will routinely trigger the job after a Ziti release. I see there's already a plan to auto-release this image.
Where are notices for any CVEs or releases announced?
Releases are announced in GitHub: https://github.com/openziti/ziti/blob/main/CHANGELOG.md
We don't maintain a separate feed or channel for CVEs, but fixes are routinely mentioned in the changelog. How do you want this to work? I imagine that responsibly-disclosed vulnerabilities should remain unannounced until fixed to avoid a splatter of exploits.
Is there any further securing of the client API that can/should be done?
No, Ziti's APIs can't be fronted or proxied by an external system or service because they offer client certificate authentication, so they must terminate server TLS. This prevents intermediaries from having any ability to eavesdrop or modify the communications with Ziti's APIs, including a WAF or load balancer. A network-layer LB (NLB or L4 LB) is an exception because it will pass-through server TLS to Ziti.
For security, I recommend using one of the PKI authentication mechanisms: enrollments or claims, avoiding password authentication.
I will consider pinning the sha.
No preference on the security announcements if I know where they are. I haven’t looked into it yet, but if I can subscribe to the changelog, all the better.
Good news that the API stands alone… much simpler for me 
Thanks for the responses!
1 Like