Establish whether Remote Config Mgmt is enabled so CLI can deliver better errors to the user

dopey commented 2 years ago

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

After the merging of the beta ca provisioner subcommand into mainline, the CLI has to decide for the user whether to use Remote Config Mgmt or local config mgmt (whereas before step ca provisioner was always local). Add an endpoint to the CA that returns whether the CA is enabled for Remote Config Mgmt and hit this endpoint before every attempt at remote mgmt. If remote mgmt fails, we can return a more informative error to the user. E.g., Hey, the CLI is unable to find the ca.json. Please make sure your STEPPATH is properly set, or provide the correct location with --ca-config. If you're interested in enabling remote provisioner management, please see the documentation here xxx.

Why is this needed?

We're seeing users confused about the error messaging. For whatever reason their client can't find their ca.json so the CLI attempts to use remote provisioner management and returns an opaque error about AdminClient stuff. Users assume it's a credential issue (based on the opaque error).

hslatman commented 2 years ago

Instead of an endpoint that only returns if the admin API is enabled or not, the endpoint could return more capabilities that the CA has enabled or not. This could include things that are not available in open source, but only in the product, for example.

dopey commented 2 years ago

@hslatman good point, I'm gonna change the title of the issue to suggest that we add some sort of API that let's this stuff be discoverable. Having said that, there may be security concerns (maybe?). Like an attacker might find it useful to know whether a CA has remote config mgmt enabled or not.

dopey commented 2 years ago

After some discussion, our team has come to the conclusion that the information leak (mentioned in comment above) is acceptable and does not provide an attacker with substantial additional information.

So, we are 'ok' with establishing, without authentication, that a given CA has remote config mgmt enabled. Now the question is how best to do this? The following are some options that we have discussed:

Options endpoint that returns the allowed methods
Return 501 NotImplemented for on a given endpoint
Add an endpoint like /admin/enabled that returns whether the APIs are enabled

We will re-convene and select an option once this issue is closer to being prioritized.

If folks from the community have an opinion, please let us know. 🍻

dopey commented 2 years ago

https://github.com/smallstep/certificates/blob/713dfad88496094f495c1d17e036dc4abc881605/api/api.go#L207-L210

Another options is to add another capability in the version response. This was @maraino's suggestion. @hslatman what do you think?

hslatman commented 2 years ago

It could work in the VersionResponse, but perhaps it should then be called something more generic. It's not returning just a version now and another property will be added. We can keep it on /version for a while for backwards compatibility, but also add a new endpoint for it.

Conceptually it's not too different from the ACME directory and the meta object, but calling it that is probably confusing. In the SCEP protocol, this type of setting are the CA Capabilities.

Besides offering the endpoint, I think a 501 (or a different code), should still be sent when not adhering to the capabilities offered.

maraino commented 2 years ago

A /capabilities, /ca/capabilities, or something similar can also be added. But we should add the RequireClientAuthentication to that one too. In some cases, the cli is already using that property in the /version to decide if it needs to generate or read the identity certificate.

smallstep / cli