Closed egeldenhuys closed 6 years ago
Why should we worry about public-facing HTTPS? My opinion is that any public facing API that needs certificates can do that themselves as there are many ways to do this. Since this software can be used by anyone, we should not force them to use Let's Encrypt. If they are behind a corporate proxy with their own root certificates, forcing Let's Encrypt on them is not the correct thing to do.
Ideally, we should make our software modular such that any HTTPS proxy container or production system can be used as a front to our API.
Ahh yes, I forgot that not everyone is a student!
Then HTTPS should be provided by whoever is deploying the API. We do not have to integrate HTTPS into the API module.
As an example, NGINX allows HTTPS forwarding. We will need to think about integrating HTTPS in the local network to allow communication between say the NGINX server and Express to take place over HTTPS as well, so I'm going to reopen the issue.
Maybe let the development Docker image generate some SSL certificates for testing and the production image take the paths to the certificates as environmental variables? We'll need to look into how other open source projects handle this.
On my server I use a public facing nginx reverse proxy which manages my certificates. Based on the Host header, it serves the correct web server.
We can assume that the local machine is secure and therefore traffic on the local machine is also secure. So we do not need to encrypt traffic on the local machine to and from the Docks API.
The responsibility of HTTPS should be placed entirely on the system admin.
I concur with everything said - the responsibility of generating and providing SSL certificates will fall on the deployer of the Manager - not you guys.
The way we handle this with our projects is to have a NGINX proxy serving the entire swarm, with generated LetsEncrypt certificates.
HTTPS will be managed by an external service
Daplie/greenlock-express might solve this problem. It automates Let's Encrypt certificates. HTTPS is critical for production.
However this would require a domain name. I have a non
.xyz
domain we can test with.