freenas / iocage-plugin-nextcloud

Artifact file(s) for nextcloud iocage plugin
18 stars 35 forks source link

Allow to delegate SSL to an external proxy #50

Closed artonge closed 3 years ago

artonge commented 3 years ago

From https://github.com/freenas/iocage-plugin-nextcloud/issues/45, a valid use case was raised by @jdrouhard to allow unencrypted access to the plugin.

Maybe this isn't directly related, but what about those of us who specifically want to run Nextcloud without SSL on port 80? Is there a way we can add configuration to the plugin that simply disables all SSL-related functionality (like auto renewing certs, and reverts to running nextcloud on port 80 without TLS)?

I don't expose my Nextcloud instance directly to the internet but use a reverse proxy for various subdomains, and I do my SSL stuff there. I specifically don't want to manage my SSL certs on my nextcloud plugin.

artonge commented 3 years ago

One solution could be to allow access to the php-fpm process through port 9000 which would allow to reverse proxy nextcloud from another server.

@jdrouhard Would that work for your use case?

artonge commented 3 years ago

Another solution would be to white-list the plugin's self-signed certificates on the reverse proxy side.

artonge commented 3 years ago

Another solution would be to allow access through port 80. But I am not a fan of this, as it would add some complexity to make it conditional.

jdrouhard commented 3 years ago

One solution could be to allow access to the php-fpm process through port 9000 which would allow to reverse proxy nextcloud from another server.

I think this would work, but it'd require moving most of the actual HTTP server config to my reverse proxy and I'd no longer get the updates to that as part of the plugin (much more manual work on my part to ensure the HTTP config is sync'd).

Another solution would be to white-list the plugin's self-signed certificates on the reverse proxy side.

I'm not a huge fan of this. I'd rather not have my reverse proxy decrypt traffic and then re-encrypt for the nextcloud instance to just decrypt it again. Afterall, the reverse proxy <-> nextcloud instance is entirely internal so I don't need that connection to be encrypted.

Another solution would be to allow access through port 80. But I am not a fan of this, as it would add some complexity to make it conditional.

I think this is the option I like the best :smile: It's most similar to how the plugin was set up before this most recent version and worked flawlessly for a very long time. I think it wouldn't be too hard to make this conditional.

Include the "common" HTTP server settings in its own file (all the nextcloud-specific stuff), and then just have two templates: one that uses the self signed SSL certs and listens on 443 (with a redirect on 80), and the other can just listen on 80 without SSL. It might take a bit of refactoring since the main nginx.conf script includes some SSL-related configuration, but that can just be moved to the nextcloud-ssl template file. The init script that currently syncs the template config with the "real" config can just gain a simple conditional that decides which template to use based on the config option. You can use another config option (or the same one, for that matter) to determine whether the letsencrypt certbot cron job runs to renew certs, since that part isn't necessary for a non-SSL plugin setup.

I haven't thought about this too much yet but it doesn't seem like it'd be that bad once it's refactored appropriately.

artonge commented 3 years ago

I think this would work, but it'd require moving most of the actual HTTP server config to my reverse proxy and I'd no longer get the updates to that as part of the plugin (much more manual work on my part to ensure the HTTP config is sync'd).

True that.

I haven't thought about this too much yet but it doesn't seem like it'd be that bad once it's refactored appropriately.

Let me sleep on that, I'll try to have something early next week.