Add new resource to manage system user passwords

[Fuco1]

System users cannot be managed by the existing elasticstack_elasticsearch_security_user resource. These users are not editable, except to change their password via the change password.

I think the simplest solution is to have a dedicated resource to manage the password on system users, updating the existing resource to error when used against a system user. This has a couple of benefits:

• It's clear from the schema what fields are able to be edited
• Any attempt to manage other fields in system users will result in an error which should direct consumers to the correct resource type

---

https://github.com/elastic/terraform-provider-elasticstack/issues/66

Describe the bug The kibana_system user has metadata _reserved starting with an underscore. The elastic api does not let us set or modify metadata starting with underscore.

If I import a kibana_system user into terraform, it also loads the metadata. When I then try to update the user, for example changing the password, the request fails because the validation "metadata cannot start with underscore".

We should make sure that if the metadata attribute is not set or set to null, terraform won't try to update it.

To Reproduce

1. Create a user resource

resource "elasticstack_elasticsearch_security_user" "kibana_system" {
    username = "kibana_system"
    password = "changeme"
    roles    = ["kibana_system"]
}

and import from your cluster. 2. Change the password and apply. 3. Update fails because of metadata update validation.

Expected behavior

Do not try to update metadata if my resource does not ask for it.

Debug output

Terraform will perform the following actions:

  # elasticstack_elasticsearch_security_user.kibana_system will be updated in-place
  ~ resource "elasticstack_elasticsearch_security_user" "kibana_system" {
      + email     = ""
      + full_name = ""
        id        = "KrzMC_O7QJa0DkIaO7RRYA/kibana_system"
      + password  = (sensitive value)
        # (4 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

elasticstack_elasticsearch_security_user.kibana_system: Modifying... [id=KrzMC_O7QJa0DkIaO7RRYA/kibana_system]
╷
│ Error: Unable to create or update a user
│
│   with elasticstack_elasticsearch_security_user.kibana_system,
│   on main.tf line 52, in resource "elasticstack_elasticsearch_security_user" "kibana_system":
│   52: resource "elasticstack_elasticsearch_security_user" "kibana_system" {
│
│ Failed with: {"error":{"root_cause":[{"type":"action_request_validation_exception","reason":"Validation Failed: 1: metadata keys may not start with
│ [_];"}],"type":"action_request_validation_exception","reason":"Validation Failed: 1: metadata keys may not start with [_];"},"status":400}
╵

Versions (please complete the following information):

• OS: linux
• Terraform Version 1.1.9
• Provider version 0.3.3
• Elasticsearch Version 8.1.3

[tobio]

_reserved (and other _*) fields are set on system users, which are not editable except to change their password. This means that any request to PUT _security/users/<reserved-user> will fail. There's a discuss thread on this topic.

This means that the current implementation of elasticstack_elasticsearch_security_user will fail to manage system users, regardless of what happens with the metadata field. There seems to be two options here:

• Add a new system_user resource which only updates the password with the change password API. Change the elasticstack_elasticsearch_security_user resource to error out if it attempts to manage a system user.
• Update the existing elasticstack_elasticsearch_security_user to use the change password API when managing a system user and ignore changes to other fields.

The second option sounds confusing to understand why name changes to some users get ignored etc. Even more confusing is being required to set roles, but that field just being ignored.

[k-yomo]

Hi, I started working on this! Is there any way to identify the user is system-user? If not, it's possible to update non-system user's password with this resource by mistake.

Ah it seems we can check if “_reserved” : true exists in metadata to identify system-user.