search

auto-ssl / lua-resty-auto-ssl

On the fly (and free) SSL registration and renewal inside OpenResty/nginx with Let's Encrypt.
MIT License
1.94k stars 182 forks source link

[Suggestion] Consider using vault #87

Closed ghost closed 7 years ago

ghost commented 7 years ago

Looking at the TODO list these are two items that can (possibly?) be easily resolved simply by using vault :-

"Document and formalize the API for other storage adapters."

"Add the ability to encrypt data at rest for any storage adapter"

  1. auto-ssl can use vault as a Database Abstraction layer and allow the users to store their certificates securely in any of vault's supported database. Right now the list supports 5 databases inluding mongo dbbut the list is growing with every release. It even has a provision to store the data on S3 buckets. So besides popular databases there is a lot of flexibility in terms of storage.

  2. It has an http api so auto-ssl won't have to rely on external libraries to connect to databases making it much more easier (?) to store and retrieve certificates. Nor would there be any need for creating an api that allows people to build their own storage adapters as vault already has a custom database plugin api. This way auto-ssl can focus purely on managing lets encrypt certificates, while vault handles the storage part.

On the other hand one disadvantage that I can think of is that people might not want to be forced into using vault and may be left with no other option than to save their certs on the file system,which as the documentation points out will make it difficult to use auto-ssl in a multiple server setup (maybe saving the certs on an NFS directory might be good enough in that case?).

Would love to know your thoughts on this.

Thanks!

GUI commented 7 years ago

Thanks for the suggestion! I think leveraging Vault for storage is a great idea. Although, I guess my preference would be to offer Vault as another storage adapter in lua-resty-auto-ssl, while still maintaining our existing file and redis adapters (along with any other adapters people want to contribute). As you noted, Vault adds another dependency that people would need to run, and while it could be a great option (depending on your needs and environment), I'm not sure we want to require it's usage.

Does that make sense? But thanks for the idea, since I hadn't really thought about Vault for this, and it does make a lot of sense. With an HTTP API, it should hopefully be pretty doable to create a storage adapter for lua-resty-auto-ssl (I still need to open source the Mongo adapter I have, but it's based on an HTTP API to mongo, so there might be some similarities).

If I get a chance some day, I'll try to look into creating a Vault adapter, but pull requests for this would certainly be welcome.

ghost commented 7 years ago

Apologies! it looks like only the generic secret backened can store arbitrary data. For all other database we can only generate credentials. So I guess the purpose of this issue is defeated. Should have read more carefully. I sounded too good to be true!!

luto commented 7 years ago

Oh well. Thanks for the suggestion anyways!

ghost commented 7 years ago

Hello @luto and @GUI . Although this issue was raised wrt vault (which did not provide a unified DBAL) there is another application that does provides access to multiple databases from a single restful api, Dreamfactory.

It's written in PHP so while on one hand it adds a dependency for auto-ssl on the other it also makes auto-ssl an attractive choice for people who already use php in their stack.

What I'm thinking is this. Dreamfactory has a generic api to query and update from multiple datasources.

auto-ssl can simply implement query and update api endpoings for fetching and storing certificates and it immediately becomes compatible with all of the supported databases (which includes mongodb)

Another idea could be to provide a standard http backend like terraform with which a certificate can be fetched using a get request and updated using a POST request. All auto-ssl has to do is make the request to the supplied url and it is the responsibility of the webserver to give to give it the requested certificates on that endpoint.

Most database these days already provide a restful api so this approach can also make auto-ssl compatible with all that do.

What do you think?

dimitrovs commented 7 years ago

Whatever you do, please keep the current 0 friction "just works out of the box" setup available. I am very happy with the filesystem based solution which is in place now and I would hate to be stuck on the current version forever if future releases end up having some massive dependencies or complicated configuration.