Can an nginx container run in front of Icingaweb, without breaking GUI features?

Hi,

I’m looking from some detailed pointers on how to configure nginx in a container setup, where nginx is running ‘in front of’ (reverse proxy) icingaweb.

The compose file exposes port 443 on the nginx container and the nginx container is configured to forward the location to the icingaweb container.

This works - in that I get access to the gui and can navigate everywhere I want.

However, some basic functions of the icingaweb gui no longer work:

  • pulldown menus
  • menus are fully unfolded instead of collapsed
  • filters do not get applied
  • auto refresh does not work
  • probably others

This topic could help Icinga Web with Nginx - Icinga Web 2 - Icinga Community, and I’m going to try that. However, I’d like a sanity check from the community before I waste days trying to tweak something that is conceptually flawed.

So my questions are:

  • Can the concept of running an nginx container in front of icingaweb work, fully featured?
  • If so, should the quoted community link suffice?
  • If not, what other nginx configuration items are required?

I have decent expertise on containers and Icinga. I have little understanding about php, css and what those technologies require from nginx conf settings.

server {
    listen                                *:443 ssl;
    server_name                           some.server.com;

    client_max_body_size                  0;
    client_body_timeout                   10;
    client_header_timeout                 10;

    keepalive_timeout                     10;
    send_timeout                          10;
    server_tokens                         off;
    location                              ~ /\. { deny all; return 404; }

    ssl_ecdh_curve                        secp384r1;
    ssl_protocols                         TLSv1.3;
    ssl_prefer_server_ciphers             on;
    ssl_certificate                       /etc/nginx/ssl/some.server.com.crt;
    ssl_certificate_key                   /etc/nginx/ssl/some.server.com.key;
    ssl_session_tickets                   off;

#    errors go to docker console
    access_log                            /var/log/nginx/icingaweb_access.log combined;

    ## Header settings
    add_header                            Content-Security-Policy "default-src 'self'" always;
    add_header                            X-Content-Type-Options "nosniff" always;
    add_header                            X-XSS-Protection "1; mode=block";
    add_header                            Strict-Transport-Security "max-age=15768000;" always;
    add_header                            X-Frame-Options "SAMEORIGIN" always;
    add_header                            Referrer-Policy "no-referrer";
    proxy_cookie_path                     / "/; HTTPOnly; Secure";

    location / {
        proxy_pass                        http://icingaweb:8080;
        proxy_set_header Host             $host;
        proxy_set_header X-Real-IP        $remote_addr;
        proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_hide_header                 X-Powered-By;
        proxy_hide_header                 Server;
    }
}

This definitely works. The referenced topic is relatively dated, but doesn’t contain any obvious incompatibilities.

Your problem might be the Content-Security-Policy header. The problems you describe sound like Javascript isn’t running at all and this header might be the culprit. Icinga Web supports it since v2.12, but only if it provides it on its own. (Can be enabled in the general configuration) But then, this is still experimental as not all parts (especially Modules) have support for it.

Remove the CSP header from the server configuration, and see if that helps.

Hi,

All issues disappeared when I run nginx without the CSP in the header. So that was a great hint! Cheers.

The company policy is that it must be present, so I’ll need to check out to what extent I can still add a CSP without losing functionality.

As already said, Icinga Web only supports it, if it’s defining the value on its own, which it does if enabled in the general configuration. There’s a bug though, as it doesn’t cover Javascript yet.

In any case, default-src 'self' is too strict and cannot be used. Mainly because Icinga Web still relies on inline style here and there (If CSP is on, protected by nonces) as well as on inline fonts as part of CSS.

So you can safely add script-src 'self' in addition, but any other value isn’t supported yet.