External HTTPS Webhook for generalized registration authority

[hongkongkiwi]

Hi there,

I would like to store the Root CA in Hashicorp vault to keep it secure and use smallstep as the frontend.

I was thinking the best way is if I can configure an external ca via a webhook, so the actual CSR would be forwarded to Vault and it will come back signed to Smallstep.

[hongkongkiwi]

Ah looks like this is a duplicate of #343

[mmalone]

Before closing this as a dupe, are you just trying to keep your root signing key in Vault or do you also want to keep your intermediate there?

The reason I ask is: if this is purely a root key security issue, and all you want to do is keep that signing key in Vault, you can already configure step-ca to do this. In fact, step-ca does not need access to your root signing key at all. You can simply delete it. If this would satisfy your requirements lemme know and I can dig up some better docs for you.

If you also want your intermediate signing key to be managed by Vault then yea, we'd need a deeper integration to support that. If you're not sure what the difference is check out our everything PKI blog post. Specifically, the section titled "Intermediates, Chains, and Bundling". Happy to answer any questions if that doesn't do the job.

Note that we do have a plugin architecture that supports keeping signing keys in HSMs already.

[hongkongkiwi]

I would like to keep our intermediate signing key there.

Vault has excellent audit capabilities and we are already familiar with keeping it secure. We currently use it as a CA but we would like to use Smallstep as a frontend. To have to secure an intermediate key somewhere else on the filesystem (or even gcloud) is a bit of an extra thing, so it would be great if we could just keep the key in vault alongside all our other secrets and have smallstep make a call to auth with vault, grab the intermediate key and store it in memory for signing. OR call it everytime it wants to sign.

[mmalone]

Thanks @hongkongkiwi.

We hear this a lot: people want to centralize key management and audit in one place. But, if we just use Vault for escrow (e.g., grab the intermediate from Vault and store it in memory) then you wouldn't get the Vault audit records, right?

[hongkongkiwi]

I guess there's two things, Audit and Centralisation.

In terms of Audit, there is a record everytime the intermediate key is accessed, your correct in a sense that we don't have a record within Vault of what the intermediate key was used for, I suppose in that way Smallstep should supplement this with it's own logging capabilities. So it's not perfect.

Most importantly is centralisation. Right now, we have Vault keeping our records (in this case any keys) encrypted and access controlled via an AppID/Secret. If there is a security breach, we can immediately seal the vault keeping everything safe and it requires a quorum to unseal (e.g. 3 staff members). By allowing us to keep the intermediate key inside Vault Smallstep benefits from this.

If we use CloudKMS for keeping Smallstep keys, we have to secure another attack vector besides Vault since we are already using Vault for secrets.

So in this way, centralising means that we can both control when smallstep is allowed to access the intermediate key and if we need to seal the vault we can do so and know that all secrets are secure without wondering if anybody has access to our google key.

Vault is a specific (I guess common) use case, but I would propose a more general interface that can call an external script. That way it could be connected to any kind of legacy API :) Ideally direct Vault integration would be great, but an external plugin interface that's simple would be really good too.

[TheSecMaven]

Doesn't vault have a server integration? meaning it can take a secret out of vault and store on a file on the server? Seems like that may simplify this, I know CyberArk Conjur has a solution like that.

[maraino]

Although it hasn't been officially announced yet, we have added support for this kind of integrations, currently, only Google's CloudCAS is supported, but other registration authorities can be supported using the following interfaces: https://github.com/smallstep/certificates/blob/master/cas/apiv1/services.go#L7-L26

[hongkongkiwi]

Is it possible to add a HTTPS webhook interface? I'm not a Go developer and would love to just keep the system clean without adding my own code in.

With a webhook provider we can just use a simple interface to handle external certificate calls.

[maraino]

@hongkongkiwi it will be possible to add an HTTPS webhook interface that we will POST a JSON with the certificate that we want to sign.

We cannot directly use a certificate request, that can be checked because we don't have the private key to sign the CSR. Certificate templates do transformations on the CSR to get the final certificate.

But as a configuration option, we can provide the raw certificate in case the external CA will take care of that.

A design is required first because we need to figure-out mostly the authentication and data formats.