[Feature] Don't remove the Elasticsearch authentication on resource-level `elasticsearch_connection`

[Zawadidone]

Is your feature request related to a problem? Please describe. The Elasticsearch authentication on resource-level elasticsearch_connection will be deprecated, which forces the usage of a provider that uses hardcoded credentials or a provider that depends the resource ec_deployment.

Using a hardcoded provider goes against the principle of using a single Elastic Cloud Terraform provider to configure multiple deployments that have Elasticsearch resources. Defining the the Elasticsearch authentication on resource level suits usage of the Elastic Cloud Terraform provider.

If a Terraform module that contains an Elastic Cloud deployment with Elasticsearch resources is destroyed, the Elasticsearch resources can't be deleted because the Elastic Stack Terraform provider is also destroyed in the same run (https://github.com/elastic/terraform-provider-elasticstack/issues/509#issuecomment-1871112920).

Notice that the Elastic Stack provider is not configured, since we'll be using an elasticsearch_connection block for each of our resources, to point to the Elastic Cloud deployment. This is because terraform can not configure providers that are dependent on one another. - https://github.com/elastic/terraform-provider-elasticstack/pull/16/files#diff-b9b7a6e1524a6af9ff3c316d95a6dd1fa5b95d95e130de3ed83228f34e8b4929R40-R41

This issue is related to https://github.com/elastic/terraform-provider-elasticstack/issues/509, because authentication on resource-level has not been implemented for Kibana.

Describe the resource you would like to have implemented. Don't remove Elasticsearch authentication on resource-level elasticsearch_connection and don't force the Elasticsearch connection via the provider configuration.

[BrianRichardson]

I completely agree with this. It seems a step backwards to move connection details to the provider configuration without providing a practical alternative technique for providing these details dynamically. We have Elastic Cloud deployments in multiple regions and am currently using resource specific connections. Without this, we would be forced to clone and then hard-code these connection details.

[cah6]

+1, I want to chime in my agreement here.

We have a use case where we will have many smaller deployments that we would like to efficiently manage with terraform, which for us manifests up as a foreach loop to create similar deployments (with the same users, roles, etc on each) based off some input config list. Because of https://github.com/hashicorp/terraform/issues/19932, it is not possible to create a provider per iteration of this foreach loop, which means that we need to utilize this resource-level elasticsearch_connection feature.

Removal of this would make our elasticstack terraform the only piece of our infrastructure that has to be explicitly listed out one-by-one.

[cwhitemaddox]

I just found this issue via the deprecation notice on the elasticsearch_connection field of the elasticsearch_security_api_key resource (v0.11.16). I have Terraform source code that interacts with multiple ES clusters across different environments (which can vary based on a changeable set of environment names in my terraform.tfvars.json). Since a Terraform provider block cannot use the Terraform for_each meta argument, I cannot use my list of environments to provide credentials to n number of providers. However, if I can specify credentials at the resource block level, interactions with those different clusters will work as expected.