How do I use the global vars in the IcingaApplication object

[soneniko]

Hello,

According to the docs that I can’t link for whatever reason (icinga2 docs > Object Types > IcingaApplication), I can use the vars attribute on the IcingaApplication object. I have specified a dict there and the config check passes but I have no clue how to reference its values in the director.

I have not found any documentation on the matter.

Best regards and thank you in advance,
Niko

• Version used (icinga2 --version)

# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.15.0-1)

Copyright (c) 2012-2025 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
  Platform: Debian GNU/Linux
  Platform version: 12 (bookworm)
  Kernel: Linux
  Kernel version: 6.1.0-37-amd64
  Architecture: x86_64

Build information:
  Compiler: GNU 12.2.0
  Build host: runner-hh8q3bz2-project-575-concurrent-0
  OpenSSL version: OpenSSL 3.0.16 11 Feb 2025

Application information:

General paths:
  Config directory: /etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /run/icinga2

Old paths (deprecated):
  Installation root: /usr
  Sysconf directory: /etc
  Run directory (base): /run
  Local state directory: /var

Internal paths:
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

• Operating System and version
  PRETTY_NAME=“Debian GNU/Linux 12 (bookworm)”
  NAME=“Debian GNU/Linux”
  VERSION_ID=“12”
  VERSION=“12 (bookworm)”
  VERSION_CODENAME=bookworm
  ID=debian

• Enabled features (icinga2 feature list)

Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb influxdb2 journald livestatus opentsdb perfdata syslog
Enabled features: api checker icingadb mainlog notification

• Icinga Web 2 version and modules (System - About)

• Config validation (icinga2 daemon -C)
  config is valid

[lorenz (LorenzK)]

Hi @soneniko,
could you formulate what you intend to do? Some context might help here.

[moreamazingnick]

usually i would start with:
Why do you need that? There is most likely another way.

But I got curious and here we are now:

The object with the vars dictionary:

a command that executes /usr/bin/echo:

an argument with no key and the value generated by icingadsl:

o = get_object(IcingaApplication, "app")
return o.vars.colour

…

IcingaDirector supports icingadsl only for command arguments.

And still I want to ask, why do you need that?

[soneniko]

I need this feature to reference credentials that I wan’t to save somewhere. My current solution for storing credentials feels janky and will remain my secret but I did not find any best practices or recommendations for storinng credentials that checks might need for authenticating with APIs and such. That is why I asked the question.

I also had the idea to use environment variables for the checks that run only on the master and not on the agents, but I did not manage to get that to work either and since I needed a solution that fits both use cases I wanted to see if theres a ‘silver bullet’

Thanks for the responses. If you have another option for me, I would be grateful if you share it, as there is not much information on this stuff

Cheers,
Niko

[moreamazingnick]

Credentials are in fact a ver painful topic.

Keep in mind that for this approach:

• the inspect view shows your credentials
• the check execution is written to the database
• the process list has your credentials anyway

One approach that works with custom checks:

• create a textfile with e.g username:password
• adapt your check that it reads such a file and uses this password, so your parameter is just a filepath

of course some smart admin with director access can create a command that prints the passwordfile to pluginoutput but this would be logged in the activit log anyway.

[rivad (Dominik)]

True, I was also exchanging ideas with @elippmann and proposed something like:

object Service "service_x" {
    host = "exap.example.com"
    check_command = "cmd-check-oracle-health"
...
    zone = "master"
...
    vars.oracle_health_password = "$icinga_credential|service_x.oracle_health_password$"
    vars.oracle_health_username = "$icinga_credential|service_x.oracle_health_username$"
...
}

object Credential "service_x" {
    zones = ["master"]
    oracle_health_username = "ICINGA_SELECT"
    oracle_health_password = {{{ICINGA_VAULT|1.1|AES256
      64333638646162396238653334626130326664366235646663623262303334623239346531636139
      6163633021346232306566343234306137626138623036360a636163633862393238383834383761
      61326366343337386634333135303232353566313630336266646537383037306363646630666436
      3634626364343335380a613136656639313862313766646335616562626361643866306462663566
      3739}}}
}

and access them like mentioned here: Command line argument values written as part of check_commandline to icingadb could contain credentials · Issue #932 · Icinga/icingadb · GitHub

[soneniko]

This seems like a good idea. Provisioning credentials in a file requires me to deliver that file to the server that the agent is running on, which is less than optimal. I would really like an option to reference credentials like this.