Security¶
Icinga DB Web allows users to send commands to Icinga. Users may be restricted to a specific set of commands, by use of permissions.
The same applies to routes, objects and variables. To these, users can be restricted by use of restrictions.
Permissions¶
Restricted Command Permissions:
If a role limits users to a specific set of results, the command permissions or refusals of the very same role only apply to these results.
| Name | Allow… |
|---|---|
| icingadb/command/* | all commands |
| icingadb/command/schedule-check | to schedule host and service checks |
| icingadb/command/schedule-check/active-only | to schedule host and service checks (Only on objects with active checks enabled) |
| icingadb/command/acknowledge-problem | to acknowledge host and service problems |
| icingadb/command/remove-acknowledgement | to remove problem acknowledgements |
| icingadb/command/comment/* | to add and delete host and service comments |
| icingadb/command/comment/add | to add host and service comments |
| icingadb/command/comment/delete | to delete host and service comments |
| icingadb/command/downtime/* | to schedule and delete host and service downtimes |
| icingadb/command/downtime/schedule | to schedule host and service downtimes |
| icingadb/command/downtime/delete | to delete host and service downtimes |
| icingadb/command/process-check-result | to process host and service check results |
| icingadb/command/feature/instance | to toggle instance-wide features |
| icingadb/command/feature/object/* | to toggle all features on host and service objects |
| icingadb/command/feature/object/active-checks | to toggle active checks on host and service objects |
| icingadb/command/feature/object/passive-checks | to toggle passive checks on host and service objects |
| icingadb/command/feature/object/notifications | to toggle notifications on host and service objects |
| icingadb/command/feature/object/event-handler | to toggle event handlers on host and service objects |
| icingadb/command/feature/object/flap-detection | to toggle flap detection on host and service objects |
| icingadb/command/send-custom-notification | to send custom notifications for hosts and services |
| icingadb/object/show-source | to view an object’s source data. (May contain sensitive data!) |
Restrictions¶
Filters¶
Filters limit users to a specific set of results.
Note:
Filters from multiple roles will widen available access.
| Name | Description |
|---|---|
| icingadb/filter/objects | Restrict access to the Icinga objects that match the filter |
| icingadb/filter/hosts | Restrict access to the Icinga hosts and services that match the filter |
| icingadb/filter/services | Restrict access to the Icinga services that match the filter |
icingadb/filter/objects will only allow users to access matching objects. This applies to all objects,
not just hosts or services. It should be one or more filter expressions.
icingadb/filter/hosts will only allow users to access matching hosts and services. Other objects remain
unrestricted. It should be one or more filter expressions.
icingadb/filter/services will only allow users to access matching services. Other objects remain unrestricted.
It should be one or more filter expressions.
Denylists¶
Denylists prevent users from accessing information and in some cases will block them entirely from it.
Note:
Denylists from multiple roles will further limit access.
| Name | Description |
|---|---|
| icingadb/denylist/routes | Prevent access to routes that are part of the list |
| icingadb/denylist/variables | Hide custom variables of Icinga objects that are part of the list |
icingadb/denylist/routes will block users from accessing defined routes and from related information elsewhere.
For example, if hostgroups are part of the list a user won’t have access to the hostgroup overview nor to a host’s
groups shown in its detail area. This should be a comma separated list. Possible values are: hostgroups, servicegroups,
users, usergroups
icingadb/denylist/variables will block users from accessing certain custom variables. A user affected by this won’t
see that those variables even exist. This should be a comma separated list of variable paths. It is
possible to use match patterns.
Protections¶
Protections prevent users from accessing actual data. They will know that there is something, but not what exactly.
Note:
Denylists from multiple roles will further limit access.
| Name | Description |
|---|---|
| icingadb/protect/variables | Obfuscate custom variable values of Icinga objects that are part of the list |
icingadb/protect/variables will replace certain custom variable values with ***. A user affected by this will still
be able to see the variable names though. This should be a comma separated list of variable paths.
It is possible to use match patterns.
Formats¶
Filter Expressions¶
These consist of one or more filter expressions.
Allowed columns are:
- host.name
- service.name
- hostgroup.name
- servicegroup.name
- host.user.name
- service.user.name
- host.usergroup.name
- service.usergroup.name
- host.vars.\<variable path>
- service.vars.\<variable path>
Match Patterns¶
Match patterns allow a very simple form of wildcard matching. Use * in any place to match zero or any characters.
Variable Paths¶
Icinga DB Web allows to express any custom variable depth in variable paths. So they may be not just names.
Consider the following variables:
vars.os = "Linux"
vars.team = {
name = "Support",
on-site = ["mo", "tue", "wed", "thu", "fr"]
}
To reference vars.os, use os. To reference vars.team.name, use team.name. To reference vars.team.on-site,
use team.on-site[0] for the first list position and team.on-site[4] for the last one.
Combined with a match pattern it is also possible to perform a contains check: team.on-site[*]