Config option to disable/deactivate a provisioner

[Messj1]

First of all thanks a lot for the CA Server and the CLI Client. The first one that made sense to me. 🥇

What would you like to be added

An option to de-/activate a provisioner, so the provisioner gets unable to create or sign new certificates.

Why this is needed

With this option it is possible to run 2 certificate authorities, one with public interface (to revoke and renew) and one with a private interface (create and sign).

Currently it is only possible to change the configuration to an "illegal" runtime value like a "wrong" secret.

[maraino]

@Messj1 It might be a good idea to do this. The best way right now to achieve this would be to configure a template that always fails, for example, something like this:

{{ fail "Provisioner cannot sign TLS certificates" }}

And the same SSH if it's enabled in that provisioner.

[Messj1]

@maraino Since I work with x5c provisioner my solution is/was to use a leaf certificate as root certificate, so it is in every case an invalid certificate. (Hope so. Would love some feedback from you.)
But thanks a lot for the hint with the template. Your idea with the template seems easier then mine with the ca config. And it works in every case. 👍

echo "{{ fail "Provisioner cannot sign TLS certificates" }}" >> /path/to/template
or
step beta ca provisioner update <name> --x509-template=</path/to/inactive.tpl> --ssh-template=</path/to/inactive.tpl>

Best would be to have a flag in ca.json and also a new flag in step-cli:

step beta ca provisioner update <name> --state=inactive

And again:
Love the project, like the people behind the project. Commands and configs I can remember as a non sys operator 🥇

[maraino]

Your trick with the X5C can work, but I wouldn't rely on it, we might add a check to make sure you add a CA certificate in the future.

By the way, the step beta ca * commands are in the process of transitioning to step ca *, there's an open PR for it. The new version will work for configurations in the database as well as configurations in the ca.json. Currently step beta only works if your database is the one holding the provisioner configurations.

I don't think an inactive state will come soon, what does it mean? does it mean just signs, just renewals, ... Initially we might just add a way to block X509 operations on a provisioner similar to enableSSHCA.

[Messj1]

The idea with the state flag was more like to have an enum:

• inactive
  nothing works, no sign, renew or what else ... similary to a removed user
• suspend
  passive provisioner, so valid certificates are still "alive" and can renew themself
• active (default)
  user can work as expected (create/sign certificates active)

So it would be expendable for future ...

I know, the naming could be better. But you know create names is a hard business. 😉

[dopey]

First of all thanks a lot for the CA Server and the CLI Client. The first one that made sense to me. 🥇

Hey @Messj1, thanks for opening the issue! And we appreciate the compliment - thanks for taking the time to try it - we appreciate it :]

We agree that the features you've spoken about -

• inactive, active, suspended type states
• feature flagging list e.g., [x509-renew, x509-revoke, ssh-renew]
  would be useful.

We have to be quite ruthless about prioritizing open source features, generally throwing our limited resources behind those issues that have the most community support. We'd love to see some more support (in the form of 👍 or the like), discussion, or use cases from the community before prioritizing internally. Relatedely, if anyone from the community is interested in working on this issue, let us know and we can set up some time to discuss.

cheers 🍻

[redrac]

Just commenting that the feature flagging list and inactive/active/suspended states would definitely be used by our company as well. Along with something like enableX509CA similar to the existing enableSSHCA.

Just as an example use case, we are creating SSH host certs via a JWK key that is deployed globally into multiple clouds/hardware hosts via config management which then creates SSH host certs. We only want this provisioner to be able to create SSH host certs since the key is everywhere and potentially exposed. Currently we resolve this by doing what @maraino suggested and creating custom templates where all x509 certificates will fail and one for SSH where user certs will fail:

{{- if eq "user" .Type }}
{{ fail "Provisioner cannot sign SSH user certificates" }}
{{- else }}
...
{{- end }}