search

slackhq / nebula

A scalable overlay networking tool with a focus on performance, simplicity and security
MIT License
14k stars 938 forks source link

Support for HSM (Hardware Security Module) or PKCS#11 #328

Open dbeecham opened 3 years ago

dbeecham commented 3 years ago

This is similar to issue https://github.com/slackhq/nebula/issues/51, but not immediately equivalent. It would be neat to be able to put the CA certificate key on a HSM module like the YubiHSM. If nebula-cert could have support for PKCS#11, it could store the private key on any PKCS#11 module such as the YubiHSM. Nebula doesn't strictly need to use x509 certificates for this, it could just store the private key pair on the HSM, but if it did use x509, that support would be automatic since we could use openssl/gnutls to generate the certificates on the HSM or on Hashicorp Vault ourselves.

cwichura commented 3 years ago

Seconded. PKCS#11 bindings would support many HSMs. But for full support, would need (configurable?) hooks to have it call out to log in to a networked HSM cluster, such as Luna SA.

kevin-fibich commented 3 years ago

I think this issue should to be extended to a change/clarification of nebulas solution design, since a couple of problems arise from nebulas current approach to certificates (nebula style certificates).

IMHO and from a design perspective, nebula should not deal with any technical details or specific implementations regarding the PKI system. Instead it should define an API signature of what functionality it requires in regards to Authentication/Authorization and make the specific implementation plugable. The current implementation could of course serve as a default module and retain things like the nebula-cert tool but why do we limit nebulas design to that specific implementation? This will only create drag down the line because nebula then needs to chase functionality that already exists elsewhere, be it HSM support, certificate rollout, revocation support etc. If we instead externalise these issues and make the implementations plugable it would become much easier to benefit from the value already created by other solutions and at the same time enable devs to focus on actual nebula functionality. Dropping the whole PKI thing for a PSK or even no auth at all? Or maybe use some next-gen quantum key distribution system? As long as the implementation can satisfy the requirements such an API would present, i believe nebula does not benefit from enforcing a specific one. Some use-cases could even call for multiple implementations at the same time, like using certs like today but getting unsafe_routes via a bgp peering with the lighthouses or some k8s CNI. And seperating out this functionality could also reduce the amount of potential security vulnerabilities specific to nebula (that need to be fixed by nebula devs)

The only drawback i see is that this could increase complexity and someone with little experience could set up nebula in a way that is not as secure as that person expects.

dumbasPL commented 7 months ago

It's been over 2 years, any progress on this?

johnmaguire commented 7 months ago

Hi @dumbasPL - this issue is a feature request, not a tracking issue. I don't know of anyone working on this feature. The best way to show your support is to react to the original issue with a 👍 - this allows maintainers to sort issues by votes.