Allow setting provisioner claim settings from step ca provisioner create

[dopey]

Allow setting provisioner claim settings from step ca provisioner create

... as well as updating them through something like step ca provisioner update ...

General process improvement around managing provisioners.

Why?

The only way to currently add claims to a provisioner is to modify the JSON configuration (either by hand, or using another tool e.g. jq).

Questions

• Should this be part of a larger effort to update CRUD processes for provisioners? e.g. API, storage backend, removing them from configuration

[mpskovvang]

This feature would be really useful!

I'm currently using step-ca together with Traefik in my local development environment to easily provision certificates. Unfortunately, the certificates only last for 24 hours by default and have to be renewed very often.

I tried to improve the dockerized version of step-ca with jq to modify the ca.json, but I don't know how to modify the JSON file.

The following command adds the claims:

jq '.authority.provisioners[] | select(.name=="development") + {"claims":{"maxTLSCertDuration":"2160h","defaultTLSCertDuration":"720h"}}' ca.json

Output:

{
  "type": "ACME",
  "name": "development",
  "claims": {
    "maxTLSCertDuration": "2160h",
    "defaultTLSCertDuration": "720h"
  }
}

The complicated part is to merge the nested subdocument with the original JSON document.

Until this feature gets implemented, can you please document how to use the jq command to modify the ca.json file?

Thanks for a great project! 👍

[dopey]

Hey @mpskovvang, I'd say we generally just go in and modify the ca.json by hand (using a text editor, e.g. vi). But that's because we've had a lot of practice.

I played around with jq a bit and think I have something that will work for you.

$ cat ca.json | jq '.authority.provisioners[].claims |= (. + {"maxTLSCertDuration":"2160h","defaultTLSCertDuration":"720h"})' > ca.json.bak

Use provisioners[X] to specify the index of the provisioner with respect to the list. So if it's the first provisioner you could leave it empty (as I did in the example above). If it's the second provisioner you would use [1]. Third -> [2]. So on and so forth.

Once you're comfortable seeing the changes in the file you'll probably get more comfortable with editing the file directly. Although, hopefully we'll provide added functionality for making these modifications through an API soon, so you don't have to get too comfortable editing directly ;)

Also, really great to hear that you're using this for local development! As developers, that warms our hearts :) If you have any further questions, or are looking for some realtime help / feedback, hop in our Gitter and say hi.

[mpskovvang]

Thank you for spending time playing with jq and providing the detailed answer. This pointed me in the right direction and I ended up with this:

jq '.authority.provisioners[[.authority.provisioners[] | .name=="development"] | index(true)].claims |= (. + {"maxTLSCertDuration":"2160h","defaultTLSCertDuration":"720h"})' ca.json > ca.json

Now I don't have to provide the index myself. Perhaps it can be simplified further, but I haven't played with jq until today.

Perhaps, if we could just create a provisioner of ACME type at step ca init, the index would always be 0.

You're right that I could just have made these changes in hand, but the whole point of using step-ca in our case is to automate as many tasks as possible. This makes it very easy for other team members to quickly spin up necessary services without any interactions.

I created a simple Docker image based on smallstep/cli and smallstep/certificates with auto-configuration. The programmatic way to configure the claims was the last missing piece.

Together with Traefik, step-ca has become an important part of our local environment. All internal and client web projects can now be started with a simple docker-compose up. Previously, each developer had to create and manage certificates themself.

So, once again. Thank you for the open-source step-ca! 🎉

[dopey]

Hey, that's great to hear. I assumed when you said "local dev" that it was just one person using it to fool around locally. Can totally understand why you'd want to automate the config setup (rather than asking multiple people to dig around in the config themselves). Also, nice update on the jq command. Wasn't sure if that was possible so thanks for replying.

And finally, thanks for linking your docker image! We often get questions from new users about the best ways to containerize and how to make changes in the containers. If you don't mind, I'll link them to your example in the future.

Super cool to hear that this is helping your team streamline local development. If you have any ideas/feedback/criticism going forward, please don't hesitate to reach out.

[mpskovvang]

You're very welcome to link to the Docker image as an example. 🙂

I expect to improve it further tomorrow with the jq command and even simpler usage without Docker Compose; something like docker run --name ca.internal --restart unless-stopped -v step:/home/step katoni/simple-acme-server.