[Serverless-observability-CDN-QA] Maps can't load external layers

[jsanz]

Kibana version:

Kibana version: Serverless observability project testing for CDN readiness

Browser version:

Firefox 124

Describe the bug:

The new CSP policy disallows Maps to load external layers from WMS or Tile providers.

Steps to reproduce:

1. Create a dashboard and add a map
2. Scroll down and select the "Web Map Service" card
3. Put this URL to load https://www.ign.es/wms-inspire/pnoa-ma

Expected behavior:

The wizard continues with the normal workflow to select a layer and a style.

Screenshots (if relevant):

Errors in browser console (if relevant):

Content-Security-Policy: The page’s settings blocked the loading 
of a resource at https://www.ign.es/wms-inspire/pnoa-ma?
version=1.1.1&request=GetCapabilities&service=WMS (“connect-src”).

Any additional context:

This issue was mentioned on a comment at #177732 (comment)

---

As described in #179061 (comment), we need to relax our CSP connect-src directive to allow connections to any https: resource.

[elasticmachine]

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

[jsanz]

cc. @elastic/kibana-presentation

[jloleysens]

This will likely need to be reworked in a way that avoids the browser calling to external domains directly. On way is to use Kibana server to call to the other domain to load this metadata. I'm not familiar enough with this feature to say what the repercussions of that are however.

[jsanz]

Thanks for clarifying, @jloleysens. Moving the management of HTTP requests from the browser to the Kibana Server is not trivial, so this needs further team discussion to prioritize.

Are CSP restrictions to be enforced by default for all Kibana versions (self-hosted, cloud, serverless)?

[nreese]

This will likely need to be reworked in a way that avoids the browser calling to external domains directly. On way is to use Kibana server to call to the other domain to load this metadata. I'm not familiar enough with this feature to say what the repercussions of that are however.

I don't think this solution will work. We used to have an option to proxy EMS requests through the kibana server. This feature received a lot of negative feedback from customers (so much negative feedback that we removed it and changed how Kibana accesses EMS). The network topology did not reflect what customers require. In many networks, the browser has access to public resources but the kibana server does not. It is very standard requirement for mapping applications to access content from 3rd party services.

[jloleysens]

Are CSP restrictions to be enforced by default for all Kibana versions (self-hosted, cloud, serverless)?

I'm thinking of serverless. But any user anyone running Kibana can configure csp for connect-src and it would have the same result.

[jloleysens]

It is very standard requirement for mapping applications to access content from 3rd party services.

Good point. It seems we self host many of the third party assets we need for maps. However, in this case we allow users to enter and call any URL they want in our client which doesn't work with CSP.

I'm not familiair enough with this feature to say but perhaps the metadata retrieval can be done another way like simply pasting it in? Or uploaded? Less ergonomic of course. Or, just for serverless, we could route through server side that could do some further sanity checks on the data returned?

[elasticmachine]

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

[jeramysoucy]

I've raised this issue with the team (Kibana security) for discussion.

[legrego]

Is the ability to load external layers a feature that's required for serverless GA? Knowing this will inform the options available to us. If we have more time to solve for this, then we can likely come up with something that satisfies your needs without completely removing the connect-src directive from our CSP.

If it is required for GA, is there a set of hosts that would satisfy the majority of our user's needs in the short term, while we work on a more configurable solution?

[nreese]

Is the ability to load external layers a feature that's required for serverless GA?

I would say yes, but this should be a question for Product.

If it is required for GA, is there a set of hosts that would satisfy the majority of our user's needs in the short term, while we work on a more configurable solution?

Its not possible to gather a set of hosts because external sources are really dependent on use case and customer. For example, weather data is gathered and published by most governments. Customers will likely get weather data from their respective government. Also, with the Serverless Elasticsearch SKU, the use case could be anything. Maybe its farming and you need to see historical precipitation, or invasive species coverage, or crop yields. Customers can also host their own WMS and TileServices and expect to view these in Kibana Maps. There is no way to anticipate which services are going to be required.

The value proposition with Maps is layering contextual information on a single map. Without this, Kibana Maps is a very handicapped product.

[legrego]

Thanks, @nreese, that context is helpful. We'll respond to this issue soon with a proposal.

[legrego]

We discussed this yesterday. From our perspective, it would be ideal if we could give administrators a mechanism to control which origins Kibana is allowed to connect to (via connect-src).

That is not a small or well-defined task, and would be unrealistic to accomplish prior to GA. Given this, our next-best option is to relax the connect-src directive to accommodate your needs.

Since these resources could exist on nearly any origin, we won't be able to create an "allow list". We would also prefer not to allow all connections if possible. My question to the geo experts:

• Would it be sufficient to allow access to all https resources? Do you require the ability to contact http resources, or any other protocol except for https?

[jsanz]

• Would it be sufficient to allow access to all https resources? Do you require the ability to contact http resources, or any other protocol except for https?

Allowing loading only https resources is fair. In fact, in ESS, it is already impossible to load http endpoints because of the mixed active content policy

[legrego]

Thanks, @jsanz. We'll proceed with relaxing the connect-src to permit all connections to https: for the time being.