Support restriction in elasticstack_elasticsearch_security_api_key

[sandermvanvliet-stack]

In its current form the provider is unable to provision API keys that have a restriction specified in the role descriptors.
For example, given this terraform:

resource "elasticstack_elasticsearch_security_api_key" "api_key_with_restriction" {
  name = "restricted-key"

  role_descriptors = jsonencode({
    role-a = {
      indices = [
        {
          names      = ["index-a*"],
          privileges = ["read"]
        }
      ],
      restriction = {
        workflows = [ "search_application_query" ]
      }
    }
  })
}

The provider will happily create an API key named restricted-key however the restriction field is not persisted in Elasticsearch.

On the next terraform plan, this API key will be marked as needing replacement due to the fact that the comparison between the local terraform definition and the response from the Elasicsearch API are different. That is because the local terraform definition serializes to JSON and will contain restriction while the JSON for the existing API key does not have that field.

This PR adds the restriction to the model structs necessary to provision the API keys.

In order to achieve that, the Role struct was duplicated to an API key specific struct ApiKeyRoleDescriptor. Previously Role was shared between the elasticstack_elasticsearch_security_api_key resource and the elasticstack_elasticsearch_security_role data source.

In Elasticsearch, the restriction is only available from 8.9.x and up. To provide some feedback to users, an error will be generated during plan/apply time when the target Elasticsearch is below 8.9 and the user has specified a restriction in their local terraform definition:

Error: Specifying restriction on an API key role description is not supported in this version of Elasticsearch. Role descriptor(s) role-a

This is currently making a call directly to the Elasticsearch instance which is probably not ideal, however I could not find a reference to the current version in the code. If that's available that would be a much better option.

[cla-checker-service]

💚 CLA has been signed

[tobio]

Thanks for the addition. Looks like there's something not quite right with the docs and we can re-use the the existing ES version code rather than duplicating it, sorry it wasn't obvious how to access this.

[tobio]

Can replace this with something like

Suggested change

	if esClient, err := client.GetESClient(); err == nil {
	req := esapi.InfoRequest{}
	res, err := req.Do(ctx, esClient.Transport)
	if err != nil {
	return false, err
	}
	defer res.Body.Close()
	var info info
	err = json.NewDecoder(res.Body).Decode(&info)
	if err != nil {
	return false, err
	}
	currentVersion, err := version.NewVersion(info.Version.Number)
	if err != nil {
	return false, err
	}
	supportedVersion, _ := version.NewVersion("8.9.0") // restriction is supported since 8.9.x
	if currentVersion.LessThan(supportedVersion) {
	return false, err
	}
	}
	return true, nil
	currentVersion, diags := client.ServerVersion()
	if diags.HasError() {
	return true
	}
	return currentVersion.GreaterThanOrEqual(APIKeyWithRestrictionMinVersion)

[sandermvanvliet-stack]

Let me give that a go

[sandermvanvliet-stack]

@tobio I made a slight variation but it now uses the ServerVersion call from the client directly instead of making the whole request objects like I had before.

[tobio]

Hey @sandermvanvliet-stack are you able to sign the CLA so we can continue with this one?

[sandermvanvliet-stack]

@tobio I'm still waiting on some internal comms before I do that. Trying to figure out if we have/need/want a corporate CLA for this.

[sandermvanvliet-stack]

@tobio the CLA should now be signed as a company wide one by our teams, would you be able to check so we can get on the merge train?

[tobio]

the CLA should now be signed as a company wide one by our teams

I can't see any signed agreements from your company or email domain. I'm not familiar with the company wide agreement process, I'll ask around and see if there's something we need to do.

[tobio]

@sandermvanvliet-stack we can't find any recent CLA activity on anyone related to Stack Overflow or Stack Exchange. Are you able to get some more details about how the CLA was signed so we can try and track this down?

[sandermvanvliet-stack]

@tobio I was told it was handled but let me prod some people here. Thanks for checking 👍

[sandermvanvliet-stack]

@tobio the CLA was signed 26th of June. The contact listed is David Whitt.
I've got a copy here of the signed CLA, let me know if you need one

[tobio]

the CLA was signed 26th of June. The contact listed is David Whitt.

Ok, weird. I can't find anything under that name where we'd expect it to be (our internal tooling or in the Docusign account used for the CLA agreements). I've followed up via email so you can share a copy of the CLA. Once I've got a copy I can try and find out what's happened here.

At the very least, IIUC we should be able to manually add your accounts with a copy of the agreement.

[tobio]

@sandermvanvliet-stack sorry about the delay here. I'm not clear why it took a while for this agreement to show up. It looks like everything's good to go here.

Thanks for taking the time to add this into the provider, and dealing with the box ticking :)