elastic/support-diagnostics

Set new header for diag requests to Kibana on serverless

jloleysens opened this issue · 8 comments

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

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

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.

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?

@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"