[Bug] elasticstack_elasticsearch_security_api_key expired keys

[marchenko1985]

Describe the bug

Not sure if that's a bug or feature request

To Reproduce

imagine you have created an api key like so: (nothing special, bare minimal example) and wish to sync it to key vault

resource "elasticstack_elasticsearch_security_api_key" "example" {
  name             = "example"
  expiration       = "30d"
  role_descriptors = jsonencode({}) # not actually used, but triggers terraform to recreate api key, if not passed
  metadata         = jsonencode({})
}

resource "azurerm_key_vault_secret" "example" {
  name         = "example"
  value        = elasticstack_elasticsearch_security_api_key.example.encoded
  key_vault_id = data.azurerm_key_vault.example.id
}

Expected behavior

After month, I am expecting terraform to somehow notice that apikey is changed and sync it

but nothing happens, attempts to run terraform plan says "nothing changed" 🤔

and because of that, all other resources that rely on apikey stops working

Versions (please complete the following information):

• OS: N/A
• Terraform Version 1.9.8
• Provider version 0.11.11
• Elasticsearch Version 8.12

Additional context

I was thinking may be it is by design and should not be updated, but then it is strange that there is no notes in docs about this

At moment, if I understand correct, the workaround will be to rely on terraform password rotation, aka:

resource "time_rotating" "example" {
  rotation_days = 30
}

resource "elasticstack_elasticsearch_security_api_key" "example" {
  name             = "example"
  role_descriptors = jsonencode({})
  metadata         = jsonencode({})
  lifecycle {
    replace_triggered_by = [time_rotating.elastic-dev.id]
  }
  # expiration = "30d" # does not work as expceted, instead use lifecycle depending on time rotating resource
}

[tobio]

@Kushmaro do you have thoughts on the behaviour here?

We could rely on Hashicorps time_rotating resource described in the issue description, in which case we should improve the documentation with an example of using that.

Alternatively we could build this into the provider. There's more work there obviously but we can provide simpler handling for managing cleaning up old keys etc.

If we're building this into the resource we should:

• Only handle rotation on an opt-in basis, this feels like a potentially bad breaking change if people don't expect expired keys to be refreshed.
• Rotate the keys with some configurable timeframe before expiry (e.g rotate_before_expiry = "5d")
• Only automatically refresh keys that have expiration set. Without this we'll have to also manage cleaning up the old keys, we should instead rely on Elasticsearch to handle that for us.