lego
lego copied to clipboard
go-acme
Initial proposal for attachable storage providers
I'm currently working on a scalable solution for certificate generation. Meaning that we can run your application inside container and it can stop/start/recreated at any time, we can run several instances of this solution to overcome rate limit per IP and still get it working the same way. In order to persist certificates, I've decided to develop storage providers for you project. It is overly simplified version and work in progress, but I tend to create smaller PRs so you can review them faster, rather than huge PR which is nightmare to review. Please let me know if you see anything I should address
we can run several instances of this solution to overcome rate limit per IP and still get it working the same way
This does not sound like a good idea. The tighter rate limits imposed by Let's Encrypt are scoped by the names on the certificate, not only the IP address. Why are you trying to circumvent the rate limits?
The initial idea was to move certificates to some reliable storage, outside of local disk, and make overall solution cloud friendly. But as a side effect it gives anyone possibility to run several instances of registration tools and solve IP limits, as it is stated in rate limits:
You can create a maximum of 500 Registrations per IP Address per 3 hours. Hitting this rate limit is very rare.
We want to store certificates in some persistent storage, such as s3 or Vault, files are bitch to manage in container world. This PR provides the required functionality (no vault yet, but this is a plan), are you interested?
I think @xenolf and I will look at this again after lego is updated for ACMEv2!
@mholt any news on this? It would be nice to store certificates in storages like an azure key vault.
I really like this idea and for my own use will probably pick this PR up and make it work in the current lego version; I was just looking into implementing certificate storage in S3 and AWS Secrets Manager and this looks like a good start.
Once done, would love to see it merged; should that go in a new PR?
To clarify, the lego library does not need storage, as it can operate within memory. It's only the lego command that would use this.
FWIW, CertMagic, an upstream importer of lego, already has a storage interface defined, with several providers implemented and more to come.