Let step ca provisioner update set the templateFile option of a provisioner

[ghost]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

According to the documentation (https://smallstep.com/docs/step-ca/provisioners), a provisioner option can be (for x509 and ssh) the name of the template file.

For remote provisioners from a database, the options can't be edited easily.

Although step ca provisioner update / step ca provisioner add commands allow for the content of a template file to be set (--x509-template=.../--ssh-template=..., there is no way to set the templateFileoption of a provisioner.

Why is this needed?

In an environment with multiple provisioners, e.g. one provisioner for each administrator, provisioners are stored in a database (known as "remote provisioners") and the provisioner options can't be edited easily.

Futhermore the template file must be readable by a user to be included by --x509-template/--ssh-template. If the access to the CA from remote this is not possible.

By adding an option to set the templateFile option (e.g. --x509-template-file=...) termplate files can be used and even enforced on the server side in a complete remote (remote access and remote provisioners) setup.

[maraino]

If the provisioner is stored in the database, don't you think it makes more sense to use the database to store the template too, so step-ca and administrators do not have to bother with permissions? That is what the current flags do, at least it's what they are supposed to do.

[ghost]

Oh, never thought about storing the template in the database too.

[ghost]

For the sake of completeness, I think something like --x509-template-file/--ssh-template-file should be added with a low priority.

[dopey]

Hey @Bobobo-bo-Bo-bobo 👋 . Thanks for opening the issue!

We purposely chose to leave out flags for setting the x509-template-file and ssh-template-file when updating our provisioners CRUD API. The purpose, as @maraino mentioned, is to move towards storing everything in the DB. I can totally understand the value in simply pointing your CA at a file and then relying on config mgmt to manage the contents of the file, without needing to worry about updating the CA. It just doesn't align with how we're thinking about managing CA configuration data moving forwards.

That said, I'm happy to leave this issue open. If we see more engagement from the community, we'll bring it around and discuss again.

Cheers 🍻

[dopey]

As an aside @Bobobo-bo-Bo-bobo, which DB backend are you using?

[ghost]

Storing everything in the DB is a good thing. To point it to a file was a mere workaround to archive a more centralized configuration.

In my setups the database used is PostgreSQL.