Hey, I’m trying to get hands on OpenZiti by trying to Automate the installation process using Ansible, but I can’t really understand how the express install PKI and certs are generated. Is there any documentation, video or something else I can follow along to reproduce this step ?
There’s no great doc for what expressInstall does, at the moment. I’ll try to remember to narrate a quick video that explains it later this week (I’m away from a decent microphone at the moment).
The hope was that the bash script was enough of a guide, I but understand that reading it has become daunting over time.
If you scan through the script looking for " pki " you’ll find all the places where commands get run which are relevant. Note that the expressInstall goes a bit overboard. I feel like this would make for a good ziti tv episode though. Until then, the best thing we have is probably to read the bash.
Hopefully that helps somewhat?
Correct, there’s not yet an Ansible role for configuring the OpenZiti Controller. Here’s what we have so far: GitHub - openziti-test-kitchen/ansible-collection: Ansible Galaxy Collection of Playbooks, Roles, Plugins, and Modules
The Ansible Collection repo is a good place to share anything else we come up with using Ansible. I’d love to help out if you feel like it’s something others would use too. I’m betting there will be demand for an Ansible playbook that configures the OpenZiti Controller.
With minimal improvements to accommodate the
ziti sub-command re-organization, you might be able to use this existing role to manage the placement of OpenZiti binaries in the filesystem: ansible-collection/community.openziti/roles/openziti_download at main · openziti-test-kitchen/ansible-collection · GitHub
I’ll peek at
expressInstall too to see what an Ansible Task would look like for generating the PKI.
expressInstall is designed to be instructive for how OpenZiti can use different CAs for different crypto functions.
expressInstall takes this a step further by using both a root CA and intermediate CA for each trust root.
OpenZiti can, however, use a single CA for all crypto functions and will do so by default unless separate CAs are configured. There’s no requirement to have an intermediate CA, though there may be advantages depending on your situation.
I suggest we start with a simplistic Ansible Task that creates a single root CA and configures the OpenZiti Controller to use that same identity for all crypto functions, i.e., control plane (ctrl), edge signer, and server certs for its APIs.
That simplistic configuration will point the way to separate concerns with different roots of trust and intermediate CAs for the different crypto functions performs by OpenZiti Controller.
I’ve sketched out the ideas I mentioned in these GH issues:
For the PKI generation part, I’ve some WIP work on an ansible module that does this, basically, it takes params and maps them to ZITI Cli params.
On this module, I’ve put everything on a single module, idk if it’s a good idea or we should have one module per PKI component (one for ca, another for intermediate, etc).
Both approaches have pros/cons, pros of separating everything is that we’ll end up with few parameters on every module, code will be more maintainable also, but the cons is that we would duplicate some code (very few).