External URL allow list service

[streamich]

We need to create a global allow list of external URLs to which Kibana users will be allowed to navigate away from Kibana. One user of such service will be URL drilldown but I believe there are many more potential users. For example, all Markdown links could be checked against this allow list before navigating to an external URL.

Food for thought:

• The service could be opt-in or opt-out.
• List of allowed external URLs* could live in kibana.yml.
• How granular should we verify the URL? Should we verify origin—protocol + domain + port?
• Should we support wildcards http://google.com/*?
• Shall there be an option to allow all URLs *?
• Will the service be available on client or server? Or only on the server?

I'm pinging Security and Platform teams as in our discussion these two teams were considered as likely owners of this service.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[streamich]

@elastic-jb we will need this implemented by Security or Platform team for URL drilldown to support external URL allow list

[arisonl]

Watcher has a relevant setting too: xpack.http.whitelist

[legrego]

Thanks for opening this @streamich.

• The service could be opt-in or opt-out.

++, I think we could default to a permissive allow-list which allows all external URLs.

• List of allowed external URLs* could live in kibana.yml.

This makes sense to me as well. I could see a future where this becomes a space-aware advanced setting, but it doesn't strike me as something we necessarily want to expose right now, since we don't have granular access controls over these settings today.

• How granular should we verify the URL? Should we verify origin—protocol + domain + port?

I haven't given this a ton of thought yet, but I think we could ideally support the host-source formats that CSP permits. This gives the flexibility of optionally specifying scheme and port (I think we can ignore the path property for this)

• Should we support wildcards http://google.com/*?

I think wildcards for scheme and host are acceptable (see previous answer regarding host-source), but I don't know if we need the granularity of path restrictions. I'm not saying we don't, but we can potentially reduce scope by omitting that for the first phase if it makes sense to do so.

• Shall there be an option to allow all URLs *?

Yeah, I think this could be the default experience, which gives the impression of opting out of this service, without having to explicitly disable it.

• Will the service be available on client or server? Or only on the server?

This might live in both places. I expect we would want to ensure that any redirects that the server attempts to issue comply with the specified rule set. Again, I haven't given this a ton of thought yet, though.

[joshdover]

Just a friendly reminder that Elastic is moving away from loaded terminology like "whitelist" and "blacklist". We have decided to use "allowlist" and "blocklist" instead.

[elastic-jb]

Thanks Josh, I saw the conversation taking place. I missed the final guidance. Will use those terms going forward.

[legrego]

Discussed with @streamich and we think we can start with a client-side approach to fulfill their needs initially. This will also alleviate the immediate need for #45815, since the client will always know what Kibana's public URL is.

@joshdover I'm expecting that this will be a core service. Do you have any opinions on where this should live within core? core.externalUrl, core.http.externalUrl, or someplace else altogether?

[pmuellr]

Alerting has a similar setting, xpack.actions.allowedHosts - so we should figure out how to eventually deprecate that one and switch to this new one.

We're also trying to figure out how to enable all the various ssl/tls configuration options, that kinda go along with this, probably good to have all this stuff in the same place, eventually: #80120

[legrego]

I agree @pmuellr, consolidating these various config options over time makes a lot of sense to me.