Multiple improvements: HSTS, OCSP stapling, default vhost about https-portal

[SteveLTN]

Hi, thank you very much for your contribution!

The original implementation of this actually used dynamically-generated, per-site ENV variables. However, I concluded that using variable names to indicate sites is a bad idea.

IMO, you should use ENV variables for really simple configurations. If you want to do more than that, perhaps providing your own Nginx config files is a better solution.

However, I'm glad to see the security improvements. Probably we can work together to integrate them into the default config?

[OndroNR]

Ok, what are the reasons why are per-site ENV variables bad idea?

Providing per-site nginx config files could possibly lead to inconsistent configuration, as the rules must be edited manually when global change is required. Include files could solve some of this problem, but I am not yet sure of it.

I would be happy to assist with security improvements.

[SteveLTN]

Because ENV variables are supposed to have fixed keys, and use different values to indicate configurations.

I know having a variable per site would work, but it's against the convention of how people use ENV variables. So I decided not to break the convention.

As per-site nginx config file, the user can override default.conf.erb to have his own default config.

[OndroNR]

Maybe the user could add sites.yml with per site configuration?

[SteveLTN]

Is it really necessary given that you can override the per-site Nginx config?

[OndroNR]

If it is simple option, configuration file is better. Per-site nginx config could become outdated and out of sync of general config. This could introduce security vulnerabilities which would be patched in general config, but not in site specific config. This would have to be maintained manually by user.

[OndroNR]

And configuration file is simplier to setup than whole per site nginx configuration file.

[SteveLTN]

I don't think so.

An additional YML configuration file is short in length, yes. But in order to write that file, you need to learn what configuration options are. It wouldn't be quicker than simply modifying the default nginx config. And nginx config options can be found anywhere on the Internet.

Besides, if a user comes to the point where he needs to changed the default config, in most cases he knows what he is doing and he should not be limited by the coverage of yml config file.

[SteveLTN]

I gave it a second though. It might be good to implement some YAML-based config interface, for everything.

It could possibly look like this:

global:
  some_config: true

sites:
  - domain: example.com
    upstream: wordpress
    options:
      some_config: true

I'm still a bit reluctant of driving this project too far though. I will explore the possibility of doing so in the week, as well as integrating your security updates, upgrade documentation to compose file v2 format, allow ESCDA certificates, etc.

No promise though. I might feel this YAML config thing is too big.

[OndroNR]

As I think about it, YAML config could get too much complex. Maybe it could be implemented in another image based on this one.

[boonkerz]

do you think its possible add an discover mode by etcd or other storage?

because my domains are stored in etcd? currently i use hipache

[SteveLTN]

@boonkerz
Probably I wouldn't have time for this personally.

[SteveLTN]

@boonkerz
HTTPS-PORTAL is meant to make setting up a typical website easy, therefore it is opinionated and provides a pretty usable default configuration without the need of too much configuration.

If your setup is complex, you probably don't want to be limited by HTTPS-PORTAL.

[SteveLTN]

It turned out that I haven't got enough time to do this. Closing it now.