Enable letsencrypt when https external_url and no certs provided
What does this MR do?
Here we change the default value of letsencrypt['enable'] from false
to nil
.
This allows a user to specify explicit true
or false
if they want
to, and then when they don't specify we use the code in
LetsEncrypt.should_enable?
as a heuristic to see if we should enable.
The initial version of the heuristic is:
url has https AND
nginx is not disabled AND
nginx is listening to https AND (
( nginx certficate file is absent AND
nginx key file is absent ) OR
we previously were enabled
)
The furry part is the 'we previously were enabled'. As enabling the letsencrypt module creates certificate files we would then treat these as user-supplied certificates and so fail to renew or otherwise manage the lifecycle of the certificates.
- Changes default of
letsencrypt['enable']
to nil. It's falsey, but not definitive - Adds LetsEncrypt parse helper to the
letsencyrpt
attribute - Adds LetsEncrypt.should_enable? to hold the heuristic
- Adds Gitlab['letsencrypt]['auto_enabled'] to the secrets file
- Adds LetsEncrypt.save_auto_enabled to persist to the secrets file only if the ['letsencrypt]['auto_enabled'] attribute is missing from the secrets file
- Splits SecretsHelper.load_gitlab_secrets out from read_gitlab_secrets, so we can load inspect the secrets file without fully loading it.
Checklist
See Definition of done.
-
Change added to CHANGELOG.md. Not applicable for Documentation changes and minor changes. -
Documentation created/updated -
Tests added -
Integration tests added to GitLab QA, if applicable -
MR targeting master
branch -
MR has a green pipeline on GitLab.com
Reviewer Checklist
In addition to above, reviewer must:
-
Pipeline is green on dev.gitlab.org if the change is not touching documentation or internal cookbooks
References
Closes #3252 (closed)
Edited by GitLab Release Tools Bot