3 ms·

Doing this without something like Vault is very difficult. Vault is designed to provide similar guarantees to an HSM (it's a service designed to make keys usabl

by vngzs 4y ago

Doing this without something like Vault is very difficult. Vault is designed to provide similar guarantees to an HSM (it's a service designed to make keys usable but not exfiltratable), and that's essential for any long-lived certificates.

tptacek 4y ago
I don't know that I disagree with the broader point here, but long-lived certificates are what you don't want.
- archi42 4y ago
  Not GP, but I'd assume they talked about the root cert? You don't want to roll out a new one every other week ;-)
  - vngzs 4y ago
    Yeah, the root is long-lived. The ones you issue to SSH to a machine are short-lived, because they're not stored in something like Vault.
goodpoint 4y ago
Vault is not able to provide guarantees similar to an HSM.
- vngzs 4y ago
  You're right - an adversary with physical access to machines running Vault can steal keys from it. An HSM is designed to survive at least temporary physical access by an adversary. And if you have management infrastructure that lets admins access the servers running Vault, then they can exfiltrate the keys (an HSM can be configured to prevent this). There exist threats that HSMs will stop that Vault simply won't stop. But they are both systems intended to provide secure storage of key material with policy-based access to that key material. As an SSH CA, you can configure Vault to sign SSH pubkeys but never divulge the key material. Depending on your threat model, it might get you what you want for this use-case, but you should definitely be aware of the limitations of Vault's security model.