Feature request for SSH secrets engine to create keypairs (CA mode)

[nvx]

Is your feature request related to a problem? Please describe.
When using Vault with Nomad, consul-template, or Vault Agent a common pattern to create TLS certificates with the PKI engine has Vault generate both the private key and the signed certificate. By virtue of having a separate endpoint to sign a CSR for an existing key vs having Vault generate a new private key, this can ensure via policy that secret keys are rotated frequently.

Unfortunately this pattern is not possible with the SSH secrets engine in CA mode for user keys, an already-generated public/private keypair must be generated and the private key is sent to Vault for creation of the certificate. This makes it difficult to use in eg Nomad where creating the private key ahead of time is difficult (unless a long lived static keypair is stored in eg Vault KV store), and makes it impossible to enforce short key lifetimes.

Describe the solution you'd like
Duplicating the existing POST /ssh/sign/:name endpoint as /ssh/issue/:name (this follows naming of the equivalent endpoints in the PKI engine) that does not take a public_key, and instead generates a new public/private keypair internally in Vault which is returned in the response.

Describe alternatives you've considered
Scripts external to Vault could automate the generation of the certificate (although this becomes much harder within Nomad), but this can not guarantee by policy that secret keys are cycled.

Additional context
https://www.vaultproject.io/api-docs/secret/pki#generate-certificate
https://www.vaultproject.io/api-docs/secret/pki#sign-certificate

[cipherboy]

@Gabrielopesantos What about this one? You'll need to wire up a new response handler in the backend, validate the requested key type against the role, and then generate a new key pair and then largely refactor/duplicate the logic of signing.

Its not quite as easy as the other one, and I'd avoid doing the UI portion right now, but I think it should be doable since a lot of the work is already there. Thoughts?

[Gabrielopesantos]

This is going to require a deeper understanding of how the project is structured. Sure, I'll try. Thank you.

[Gabrielopesantos]

Hey, I am not sure if I understand how is this "validate the requested key type against the role" expected. Is the endpoint supposed to receive a "key type"? Shouldn't it be retrieved from the role?

I also checked the pki/issue path and it does not expect a "key type", just checks if the role's keytype is not "any".

[cipherboy]

Ah sorry, I explained that poorly :-)

If you look at the SSH Role, the key_type field will just be key_type=ca on this request. What we do have (on the role) is a map of allowed key types and lenghts in the allowed_user_key_lengths field.

This means you don't really have enough information to choose what type of key (RSA vs ECDSA vs ed25519) to generate on this request.

I think this means we probably need to add a key_type and key_bits request parameter to the ssh/issue (differing from PKI here), validate that its an allowed choice, and then create the requested key type/bits and sign it.

[Gabrielopesantos]

Hello, I have completed a first version of the implementation. Could if validate if the logic, , inputs and outputs are what is expected before start testing the implementation. Thanks.

Also, for now everything is in a single function but I could also refactor the existing pathSignCertificate to support this new case.

[cipherboy]

This is/will be part of Vault 1.12, thank you Gabriel for contributing this feature!

@nvx -- Check out the RC1 binary if you get time; there should be a new ssh/issue/:role endpoint that does this. :-)