Allow file names for the configuration of Redis TLS certificates and keys

[peteeckel]

Is your feature request related to a problem? Please describe.

I am provisioning the configuration for Icinga DB Web (and all other tools) via Ansible. One step ist to provision /etc/icingaweb2/modules/icingadb/config.ini with the required client and CA certificates for Redis, which works perfectly.

The problem arises if someone opens the configuration dialog for Redis in Icinga Web 2 and saves the configuration. On opening the dialog the certificates and keys are read and displayed in the GUI (which, at least for the key file, is problematic in terms of security, but let's keep that aside for now). Then, on save, Icinga Web 2 writes the certificates and the key to the file system and changes the configuration in config.ini to the names of the copied files.

1. This is a problem when one uses configuration sync for Icinga Web 2 nodes in a cluster setup, as the file names are unique. This can of course be overcome, but it creates unnecessary problems.
2. The bigger problem is, however, that the local copies are no longer automatically rotated on expiration (for the original files there is a process in place doing that), so the certificates eventually expire and IcingaDB Web breaks for the whole cluster.

Describe the solution you'd like

Provide an option to use file names instead of the contents of certificates and keys, and do not overwrite the configuration on save if file names have been configured.

Describe alternatives you've considered

Currently my solution is to set file permissions so that Icinga Web 2 can't overwrite the configuration files at all. However that leads to a user unfriendly error message and, in the default configuration, a stack trace. A more user friendly error message if config cannot be overwritten would be a usable solution as well.

[nilmerg]

Yeah, why not, thanks for the suggestion!

Though, I'd like to propose two "workarounds":

• Since you provision the configuration, you might better be off by disallowing configuration of modules by users at all. (Deny config/modules in roles)
• The names of the copied files may be unique, but their name is not random. It's just a combination of the content's md5 sum and a configuration suffix. If you have a rotation process in place, you could adjust it so that it rotates these files as well. (It would have to update config.ini as well, of course)

A more user friendly error message if config cannot be overwritten would be a usable solution as well.

There is handling for a less technical message. If you include the stacktrace, it is certainly possible to enhance this.

[peteeckel]

If you include the stacktrace, it is certainly possible to enhance this.

Here we go:

#0 [internal function]: Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}()
#1 /usr/share/php/Icinga/File/Ini/IniWriter.php(99): file_put_contents()
#2 /usr/share/php/Icinga/Application/Config.php(358): Icinga\File\Ini\IniWriter->write()
#3 /usr/share/icingaweb2/modules/icingadb/application/forms/RedisConfigForm.php(451): Icinga\Application\Config->saveIni()
#4 /usr/share/php/Icinga/Web/Form.php(1175): Icinga\Module\Icingadb\Forms\RedisConfigForm->onSuccess()
#5 /usr/share/icingaweb2/modules/icingadb/application/controllers/ConfigController.php(42): Icinga\Web\Form->handleRequest()
#6 /usr/share/icingaweb2/modules/icingadb/library/Icingadb/Web/Controller.php(468): Icinga\Module\Icingadb\Controllers\ConfigController->redisAction()
#7 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(76): Icinga\Module\Icingadb\Web\Controller->dispatch()
#8 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Controller/Front.php(954): Icinga\Web\Controller\Dispatcher->dispatch()
#9 /usr/share/php/Icinga/Application/Web.php(294): Zend_Controller_Front->dispatch()
#10 /usr/share/php/Icinga/Application/webrouter.php(105): Icinga\Application\Web->dispatch()
#11 /usr/share/icingaweb2/public/index.php(4): require_once(String)
#12 {main}

[nilmerg]

Thanks!