[Zabbix web] Better handle let's encrypt (and certbot) with nginx in the zabbix web role

[Kulgar]

SUMMARY

Currently, the nginx template doesn't handle let's encrypt at all installed using certbot... It would be great to add the little specific configurations that certbot adds when installing a new cert, like the "ssl_dhparam" or the included SSL configs from certbot.

Or another solution would be to just add a configuration to overwrite the nginx template used in the role, so that users can add their own nginx template.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

zabbix web - nginx role - nginx template => let's encrypt with certbot

ADDITIONAL INFORMATION

I quite don't understand, I saw this merged PR: https://github.com/ansible-collections/community.zabbix/pull/677 but I couldn't find the let's encrypt code and options anywhere in the actual role...

[pyrodie18]

The move to 2.0 removed adding and running certbot because it fell outside of the core purpose of the role. It does support the use of existing certs (https://github.com/ansible-collections/community.zabbix/blob/main/docs/ZABBIX_WEB_ROLE.md#apachenginx-configuration) but there may be a setting or two specific to Lets Encrypt that weren't included. If there are specific ones, let us know. As envisioned, we assumed that Let's Encrypt would be run after the role was completed and the vhost existed.

[Kulgar]

@pyrodie18 : well, you are right that let's encrypt will be run after the role was completed. But... what if you want to rerun the zabbix role after that?

The problem is that the role will overwrite specific configurations added by certbot for let's encrypt. So, it would be great to have a way to tell the zabbix role to include some configurations if an option is activated.

Right now, in order to deal with that, I used a little trick, in the global nginx.conf file that I upload to the zabbix server, I added this:

  {% if nginx_certbot %}
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  ssl_session_tickets off;
  ssl_prefer_server_ciphers off;
  {% else %}
  ssl_prefer_server_ciphers on;
  {% endif %}

And in my zabbix group vars, i added: nginx_certbot: true

But, it would be maybe better to have an option in your vhost template under this block:

{% if zabbix_web_tls|default(false) %}
 ...
 {% if zabbix_letsencrypt %}
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  ssl_session_tickets off;
  ssl_prefer_server_ciphers off;
 {% endif %}
  ...
{% endif %}

What do you think?

[pyrodie18]

I would variable the ssl_dhparam setting. Also if you're going to do it for nginx, I assume there are similar settings for apache that I would do also. One concern that I do have (although not sure if it will actually happen) is if you run the role with those settings PRIOR to running certbot the first time, I am relatively confident that the service will fail to start and the playbook will fail because it's trying to reference a certificate that doesn't exist.

[Kulgar]

You are totally right @pyrodie18 - then, maybe, it would be best to have sth like a "detect letsencrypt" task if a "use_letsencrypt" variable is set, that checks if the ssl_dhparams.pem file exists and if it does, then it adds the settings in nginx / apache with a registered condition?

[pyrodie18]

My own personal opinion is that we're starting to move into the realm of edge cases and things and outside of the "automate a standard deployment that supports 90% of the users". If you look at the pre-2.0.0 code base it was a mess in large part because of all of the edge cases that we tried to bolt onto it. This caused a few problems.

1. We had no way of testing the edge cases to actually make sure that they worked.
2. It became a nightmare to update the 90% solution because we had to figure out how to work around all of the edge cases.

When we started to plan 2.0.0, there were discussions about taking the collection (especially at the role level) back to the basics of meeting most people's requirements, but understanding that we weren't going to solve all of the problems. Also that we were going to limit ourselves to installing and configuring Zabbix and not the other parts that may/must happen. We stopped installing Nginx and Apache because while they are a requirement to run the web role, there is a lot more to actually getting them running. We got rid of lets encrypt because it's not required and if we're going to support that then why not every other certificate issuer out there?

Right now if you look at the web role, it allows you to specify an SSL certificate. It doesn't check to see if it's there though. The reason being is because we expect if you're telling the role to add it, that you already know its there. If for example though we did check and it wasn't there? What is the appropriate action? To fail (it already does that when the start/restart fails because of the missing cert). To just not add that line to the template (now you have a system configured in a way that you didn't tell it to).

Like I said, this is my own opinion, and I'd be curious what @BGmot and @D3DeFi if he is around and any others have to say about it.

[BGmot]

I think we can add several lines with all these valid ssl options somewhere after https://github.com/ansible-collections/community.zabbix/blob/main/roles/zabbix_web/templates/nginx_vhost.conf.j2#L75 Similar to

    {{ (zabbix_web_ssl_cipher_suite is defined and zabbix_web_ssl_cipher_suite is not none) | ternary('', '# ') }}ssl_ciphers {{ zabbix_web_ssl_cipher_suite | default('') }}

we can have

    {{ (ssl_dhparam is defined and ssl_dhparam is not none) | ternary('', '# ') }}ssl_dhparam {{ ssl_dhparam | default('') }}
... and other options here

So regardless where these options are coming from (using letsencrypt or not) if a user needs them then he can define them and they will be populated in the config. The same must be done for Apache.

[Kulgar]

@pyrodie18 I totally understand your point...

I thought about another solution that would let the users use their own template for zabbix vhost. So, if the user is setting a "nginx_custom_template" (or apache), then the zabbix web role will use that template instead of the one generated by the role.

You are right about what you are saying and the 90% situations, but then, if you stopped installing nginx / apache, then, why do you generate a vhost for them? Following your logic, it would be best to let the users create their own nginx/apache template and just giving them an "example template" that would work for most cases in the documentation.

Indeed, the first thing I tried to find to solve my problem, was a way to tell the role: I want to use my own vhost template for zabbix website. But I didn't find any options to do that.

Wdyt?

[pyrodie18]

I'm inclined to go with @BGmot idea about putting the options there and letting them define them if they want to and just leaving them blank or commenting if they don't. Also like he said, need to do this for apache too if we're gonna do it. @Kulgar if there's not an option to skip the vhost template, then ya, probably wouldn't hurt to include that. As far as your comment about giving them an example, I mean at the end of the day if someone wants to change the current template after they download the role, they can.

[Kulgar]

@pyrodie18 : indeed they can modify the template, but, for instance, I added the zabbix collection in my "requirements.yml" file. So, the collection and all its roles are downloaded in an ~/.ansible folder. It seems weird, then, to directly modify the roles within that folder. That's why I thought it may be simpler to have an option to tell the role to use a custom vhost template :-)

That would definitely solve my problem... especially as I might have to perform more customizations in the future on that vhost.

Oh, but yeah, there is an option to skip the vhost creation, named: zabbix_web_create_vhost if false, it's skipped. Actually, in the documentation, it says:

zabbix_web_create_vhost: Default: true. When you don't want to create an Apache Virtual Host configuration, you can set it to False.

I think that's why I missed it, as I understood it was only used for Apache... My bad, I should have looked at the nginx tasks :-) Then... yeah... that would make sense that I skip the vhost creation and upload my own configuration file... 🤔

Regarding @BGmot - his idea is good. But I'll go along with the "don't create the vhost" option. But still, I think you should add the options @BGmot proposes.