Set new header for diag requests to Kibana on serverless

[jloleysens]

For serverless we plan on making most of Kibana's HTTP APIs "internal". This means they will be soft blocked: requiring setting a new special header otherwise we return 400.

Note: this will only be enforced for serverless, Cloud/onprem will not be restricted in this way.
Additional note: setting the header will not cause issues for Cloud/onprem

"Internal" in this case refers only to obscuring HTTP APIs from users that want to integrate with Kibana. "Public" endpoints will be versioned, documented and be very long lived. "Internal" endpoints , especially those used by our tooling for diagnostics are not necessarily expected to change often -- we just want to prevent end users from knowing about/integrating with them given the much larger commitment that goes with making them public.

My suggestion is rather than making these HTTP APIs "public" in the sense described above, we give this tool access to "internal" HTTP APIs so that it can be used against serverless Kibana in the same way as Cloud/onprem Kibana.

Let me know what you think!

CC @xcrzx

[jloleysens]

Related elastic/kibana#162149

[111andre111]

It seems we will mark for serverless Elasticsearch APIs as internal as well making them available using the same header:
elastic/elasticsearch#93607

[banderror]

Note: this will only be enforced for serverless, Cloud/onprem will not be restricted in this way.

As far as I understand this is not true. All endpoints with access: 'internal' will return 400 if the version header is not passed, in all types of environments: Serverless and ESS.

This means that the support-diagnostics tool will not work with a large number of Kibana endpoints.

[pickypg]

All endpoints with access: 'internal' will return 400 if the version header is not passed

In the highlighted code, it's highlighting the x-elastic-internal-origin header. Was the intended header reference to meant to be elastic-api-version?

[banderror]

@pickypg The tool should send both headers in HTTP requests to Kibana API endpoints:

• The x-elastic-internal-origin can be passed to all Kibana endpoints with the same constant value, e.g. x-elastic-internal-origin: support-diagnostics
• The value for the elastic-api-version header should be (optionally) specified separately for each endpoint + version in the YAML config file, for example:

kibana_detection_engine_health_cluster:
  versions:
    ">= 8.8.2": "/internal/detection_engine/health/_cluster"
    ">= 8.11.0":
      url: "/internal/detection_engine/health/_cluster"
      headers:
        "elastic-api-version": "1"

[111andre111]

Hi folks, hi @pickypg ,

I quickly checked with an actual ESS and on-premise cluster. Our ES diagnostics are at the moment not influenced by this issue, however Kibana diagnostics is already with the follow files:

  kibana_detection_engine_rules_prebuilt_status.json
  kibana_detection_engine_health_space.json
kibana_detection_engine_health_cluster.json

The error was for all three the same:

{"statusCode":400,"error":"Bad Request","message":"Please specify a version via elastic-api-version header. Available versions: [1]"}

By some tests a simple parameter -H "elastic-api-version: 1" already returned the content. So not sure when x-elastic-internal-origin comes into play however not really a bad idea to support adding multiple headers.

I suppose with later stack versions there could be more issues with that.

[peluja1012]

Hi @111andre111 @pickypg, are there plans to add this functionality in the near future? This is affecting both Serverless and ESS at the moment. See this report on a recent SDH where we can't get the diagnostic information we need.

[xcrzx]

@111andre111 Can we raise priority for this? There's another SDH lacking some information in the Kibana bundle due to the missing version header