[FEATURE] Add support for Kibana Dashboards API **Search** endpoint to enable `terraform query` / bulk import for dashboards

[nickpeihl]

Name of the resource

elasticstack_kibana_dashboard

Describe new functionality

Summary

Terraform v1.14 introduced terraform query and list blocks to discover unmanaged resources and optionally generate resource + import blocks for bulk import (Terraform “Import existing resources in bulk” docs).

To support this workflow for Kibana dashboards (elasticstack_kibana_dashboard), the provider needs a way to enumerate dashboards in a space. Kibana’s Dashboards API GET /api/dashboards (space-aware via /s/{space_id}/api/dashboards) is the natural endpoint to back a provider list implementation.

Why this is needed

• Bulk onboarding: Many users start with existing Kibana content and want to bring it under Terraform management. Manually collecting dashboard IDs and writing dozens/hundreds of import blocks is tedious and error-prone.
• Terraform-native workflow: With terraform query -generate-config-out=generated.tf, Terraform can generate importable configuration if the provider can list resources and return identities.
• Dashboards require a search/list API: The provider can already CRUD a dashboard once you know its ID, but without a Search endpoint there’s no straightforward way to discover “all dashboards in space X”, filter by title, or filter by tags.
• Configuration generation requires optional full reads: When include_resource = true is set in a list block, Terraform expects the provider to return resource attributes as well as identities so it can generate more complete resource blocks.

What I built as a PoC (reference)

I have a PoC draft PR on my fork that demonstrates the intended UX:

• a list "elasticstack_kibana_dashboard" "all" { ... } query that pages through dashboards using the Dashboards Search endpoint
• optional include_resource = true that fetches full dashboard details for config generation
• composite identity format: <space_id>/<dashboard_id>
• note this PoC currently uses the POST /api/dashboards/search endpoint which is being replaced by the GET /api/dashboards endpoint. After [Dashboards as Code] Change Dashboards Search API endpoint to GET request kibana#258025 is merged, I can update the PoC.

Proposed change

Add provider support for the Kibana Dashboards API Search endpoint and wire it into Terraform’s list/query workflow.

High-level implementation notes:

• Endpoint: GET /api/dashboards (and /s/{space_id}/api/dashboards for non-default spaces)
• Paging: use page and per_page to iterate until fewer than per_page results are returned; respect Terraform’s limit
• Filters: query (simple_query_string over title/description), tags, excluded_tags
• Request requirements: Kibana currently appears to require x-elastic-internal-origin: Kibana and query params like apiVersion=1 (and possibly allowUnmappedKeys=true) for Dashboard API calls
• Identity: return a stable identity compatible with existing import semantics (<space_id>/<dashboard_id>)

Acceptance criteria

• The generated Kibana client (kbapi) includes the Dashboards Search API (GET /api/dashboards) and response types.
• The provider exposes a list implementation for elasticstack_kibana_dashboard that:
  • returns identities for discovered dashboards
  • supports paging and respects Terraform limit
  • optionally returns full resource data when include_resource = true (for -generate-config-out)
• Add an example .tfquery.hcl showing how to run:
  • terraform query
  • terraform query -generate-config-out=generated.tf
• Add basic tests for identity schema / list behavior

User impact / outcome

Once implemented, users can:

• run terraform query to discover existing dashboards in a space
• run terraform query -generate-config-out=generated.tf to bootstrap a local Terraform configuration
• users can use the generated.tf file to migrate and manage their dashboards using Terraform.

This makes onboarding existing Kibana dashboards to Terraform fast, repeatable, and Terraform-native.

Version Introduced

9.4.0

Anything else?

No response