Ability to configure external scripts/snippets to load on every page

[timroes]

We often see/have instances of Kibana, we need to inject customs scripts or snippets on every page, e.g. for GDPR compliance or Cookie Consent policies, or simply a custom analytics tool to analyze Kibana users behavior (see #81130).

Currently people need to write and maintain custom plugins to load those scripts. I think we should add a kibana.yml setting to core, like externalScriptUrls: string[]/scriptSnippets: string[], which core would automatically inject into every page when loaded. That way users will have the possibility to achieve usage of those external tools on their cluster without requiring to maintain a custom plugin.

Especially for the snippets having this in core would help with CSP. Currently running such a plugin requires to allow unsafe-inline in the CSP for script-src, so the script can be executed (since nonce is disabled in kibana.yml and also we could only use one static nonce). If core would handle that, we could server generate a nonce to use when rendering the script tag and in the CSP we deliver.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

I will start by expressing a concern about the feature as a whole: By doing this, we'll be exposing an official way/api to inject arbitrary scripts/code inside Kibana pages. Even if both approaches would require an operator to perform the setup (as it would either be config or plugin-based), I still wonder if we're really fine about this. @elastic/kibana-security WDYT?

Now, to get into the technicals:

With #102059, we refactored the csp config to allow additive configuration. The next (time TBD) step in mind was to allow to generate a unique nonce- id per request (and add it to the csp header) to allow to inline the bootstrap.js script. Once this is done, we could potentially use it to also inject custom scripts or snippets using the same nonce- value.

Regarding the approach:

The main advantages I see allowing this directly from the configuration file are:

• No need to maintain a custom plugin
• Could work on cloud if we want to - just need to whitelist the settings

The main advantages I see allowing plugin to register them instead:

• Only a personal opinion, but feel like a better design / separation of concerns overall
• Better isolation if the injected scripts also requires an associated plugin to function (e.g you disable/remove the plugin, it also stop the script from being injected).

Also, as a side question: Do we really need to support snippets, or would only supporting external scripts be acceptable?

[legrego]

I prefer the plugin-based approach, for the reasons that Pierre outlined above.

Additionally, a plugin-based approach offers us even more flexibility. A plugin has the ability to make decisions at runtime about the scripts being loaded (i.e. customize the script in some way based on configuration, the current user, time of day, etc.), whereas a static configuration has no such luxury. A plugin can even expose a management UI to allow this to be configured directly within Kibana if the need arises. While we don't have these requirements today, this design would facilitate such requirements without requiring more changes to core.

[lukeelmers]

Closing this issue for now -- at the moment we have no plans to implement such a feature as described here. Rather, if there are specific needs on the cloud side, we can handle any necessary implementation in the cloud plugin.

There is also some additional info sec auditing we need to do on any 3rd party scripts are being run, see #122109 (comment)