Icinga2: CORS support does not appear to be working in r2.8.1-1

[rayterrill]

Expected Behavior

CORS should work when setting access_control_allow_origin in /etc/icinga2/features-available/api.conf

Current Behavior

The Icinga2 API does not set the Access Control Allow Origin key even when configured via /etc/icinga2/features-available/api.conf

Possible Solution

Steps to Reproduce (for bugs)

1. Configure access_control_allow_origin in /etc/icinga2/features-available/api.conf like the following:

/**
 * The API listener is used for distributed monitoring setups.
 */

object ApiListener "api" {
  //accept_config = false
  //accept_commands = false

  ticket_salt = TicketSalt
  access_control_allow_origin = ["172.31.29.70"]
}

1. Restart Icinga

sudo /etc/init.d/icinga2 restart

1. Hit the API with the browser or CURL and validate that the CORS header is not set.

Context

Attempting to integrate the Icinga2 API with client-side code/AJAX.

Your Environment

• Version used (icinga2 --version):

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

Copyright (c) 2012-2017 Icinga Development Team (https://www.icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://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.

Application information:
  Installation root: /usr
  Sysconf directory: /etc
  Run directory: /run
  Local state directory: /var
  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

System information:
  Platform: Ubuntu
  Platform version: 16.04.3 LTS (Xenial Xerus)
  Kernel: Linux
  Kernel version: 4.4.0-22-generic
  Architecture: x86_64

Build information:
  Compiler: GNU 5.3.1
  Build host: 5b0d1614aaa2

• Operating System and version: Ubuntu 16.04.3 LTS
• Enabled features (icinga2 feature list):

Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog
Enabled features: api checker ido-mysql mainlog notification

• Icinga Web 2 version and modules (System - About):
• Config validation (icinga2 daemon -C):

information/cli: Icinga application loader (version: r2.8.1-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: *.portofportland.com
warning/ApplyRule: Apply rule 'General: Windows Version' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 36:1-36:40) for type 'Service' does not match anywhere!
warning/ApplyRule: Apply rule 'General: Network Adapters' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 46:1-46:41) for type 'Service' does not match anywhere!
warning/ApplyRule: Apply rule 'General: CPU Info' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 56:1-56:33) for type 'Service' does not match anywhere!
warning/ApplyRule: Apply rule 'Free Disk Space' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 81:1-81:31) for type 'Service' does not match anywhere!
warning/ApplyRule: Apply rule 'CPU Utilization' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 95:1-95:31) for type 'Service' does not match anywhere!
warning/ApplyRule: Apply rule 'CPU Queue Length' (in /etc/icinga2/conf.d/check_wmi_plus.conf: 106:1-106:32) for type 'Service' does not match anywhere!
information/ConfigItem: Instantiated 1 ApiListener.
information/ConfigItem: Instantiated 3 Zones.
information/ConfigItem: Instantiated 1 Endpoint.
information/ConfigItem: Instantiated 1 ApiUser.
information/ConfigItem: Instantiated 1 FileLogger.
information/ConfigItem: Instantiated 13 Notifications.
information/ConfigItem: Instantiated 3 NotificationCommands.
information/ConfigItem: Instantiated 210 CheckCommands.
information/ConfigItem: Instantiated 1 Downtime.
information/ConfigItem: Instantiated 2 HostGroups.
information/ConfigItem: Instantiated 1 IcingaApplication.
information/ConfigItem: Instantiated 1 Host.
information/ConfigItem: Instantiated 1 UserGroup.
information/ConfigItem: Instantiated 2 Users.
information/ConfigItem: Instantiated 3 TimePeriods.
information/ConfigItem: Instantiated 11 Services.
information/ConfigItem: Instantiated 3 ServiceGroups.
information/ConfigItem: Instantiated 1 ScheduledDowntime.
information/ConfigItem: Instantiated 1 NotificationComponent.
information/ConfigItem: Instantiated 1 CheckerComponent.
information/ConfigItem: Instantiated 1 IdoMysqlConnection.
information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
information/cli: Finished validating the configuration file(s).

• If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes. Single node/zone.

[gunnarbeutner]

Well, upon cursory examination I've come to the conclusion that our CORS implementation is broken.

Assigning to @N-o-X so he can take another stab at this.

[gunnarbeutner]

1. We should always send all Access-Control-Allow-Origin headers, no matter which Origin header was specified by the user.
2. The user should not be able to specify custom values for access_control_allow_credentials, access_control_allow_headers, and access_control_allow_methods - these attributes should be removed.
3. access_control_allow_origin should not have a default value.
4. We're missing a null check for headerAllowOrigin in HttpServerConnection::ProcessMessageAsync.
5. The values for Access-Control-Allow-Credentials (true), Access-Control-Allow-Methods (GET, POST, PUT, DELETE) and Access-Control-Allow-Headers (Authorization, X-HTTP-Method-Override, etc.) are application-dependant (i.e. they depend on how _we're_ doing requests) and should be hard-coded.

[N-o-X]

The current CORS implementation seems to work quite well. @rayterrill your problem seems to be the specified IP, because it's missing the protocol. To use google.com for example, you would need to specify https://google.com as the origin. If the origin does not match any origin specified in access_control_allow_origin, Icinga does not set the Access-Control-Allow-Origin header.

[rayterrill]

@N-o-X Wait... I tried to take a guess at what the access_control_allow_origin attribute needed since I couldn't find a full example in the docs.

The Access Control Allow Origin isn't set every time - it's only set when the origin matches? Seems like it would work much better (and allow for much easier troubleshooting) to have it set all the time if you have that property set on the server side. I never would've guessed that the problem was that the origin needed to match for it to even show the header in the response.

It doesn't look like the attribute allows * - I saw some discussion about now allowing that, but that breaks things like client-side AJAX calls to the API, since those would be executed from the client's browser and it would be nearly impossible to add each of those individually to the allowed list.

[N-o-X]

@rayterrill Yeah I completely agree on that, but it's not possible to send that header if it does not match. The reason for that is that the Access-Control-Allow-Origin header only allows to specify one origin. Icinga on the other hand, allows you to set multiple origins. So Icinga wouldn't know which origin to send.

[rayterrill]

@N-o-X That's actually pretty slick. :) What about allowing *? That would allow things to work pretty easily.

Absent this, I'm not sure how the CORS implementation could ever really work with true client-side AJAX code since the list of clients that have access to the system could be huge. This would definitely work with a more controlled server-side "proxy" approach to hitting the API - something like a NodeJS API with the URL for that API in Icinga's access_control_allow_origin attribute that performs calls against the Icinga API (using AJAX or not) on the user's behalf and returns the results. I've seen a few other people on forums setting this up to get around the access_control_allow_origin restrictions, but it seems like an unnecessary step, especially given that the API is also protected with authentication.

[Thomas-Gelf]

This last comment forces me to link my comment in the original related feature request 🙈 🙊 🙉

[N-o-X]

@rayterrill In case of an AJAX request it's not the clients IP being sent as the origin, but the URL the client is using to access the website. You might want to read a bit more about how CORS works :)

[rayterrill]

@N-o-X Def not a CORS expert. My bad. Thanks for all the detail.