Ignore security disabled HTTP response header

[kobelb]

Starting in 7.15, we began showing a toast warning whenever Elasticsearch responds with a Warning HTTP response header. This was added to explicitly support exposing CCS warnings to users.

This had the unintentional side effect of causing the following warning toast to be displayed many times when the user has not explicitly disabled/enabled security in the elasticsearch.yml:

The @elastic/kibana-security team has already implemented their own warning when security is not enabled that does so without endlessly nagging the user. As a result, we don't ever want the security disabled Warning HTTP response header from ever triggering a warning toast.

At the moment, the only way that we have to identify the security disabled Warning HTTP response header is using a regex. The @elastic/es-security team has suggested using the following: ^Elasticsearch built-in security features are not enabled.*. Using a regex is rather brittle. However, Elasticsearch will only be responding with the HTTP response header for 7.x because starting in 8.0 they will enable security by default and users will be required to explicitly disable security and the warning response header won't be sent in this situation.

FAQ

Can't ES just stop sending the HTTP response warning to Kibana?

It could; however, it would conceptually require Elasticsearch to know Kibana's implementation details and this is architecturally awkward.

How dare you suggest a hacky regex!

😬 It's not a maintainable solution, I fully admit that. However, the 7.16 branch will not be prone to change, so while the solution is brittle in theory, in actuality it shouldn't be. If it does end up being brittle, we have the opportunity to change the approach in the future.

Are we comfortable hard-coding the regex in the data.search service? It's security-related, shouldn't it be in the security plugin?

I mean, not really. However, making this pluggable to allow the security plugin to suppress this warning will be additional work for very little benefit since this code will only exist for 7.16.

Can we only create the PR against the 7.16 branch?

Sure. We don't need this code in 8.0. However, I defer to the implementing team whether this makes things easier or not.

[kobelb]

@petrklapka is this something we could have prioritized to have fixed in 7.16?

[Dosant]

@kobelb, do we need to also backport to the 7.15 branch?

[kobelb]

@Dosant sure, it'd be great if this could go out in a 7.15.patch as well.

[Dosant]

Closed by #115945 and also backported to 7.15