terraform-provider-elasticstack
                                
                                 terraform-provider-elasticstack copied to clipboard
                                
                                    terraform-provider-elasticstack copied to clipboard
                            
                            
                            
                        [Bug] Provider resets user password
Describe the bug If I create a User resource and they then change their password in Kibana, if I then subsequently update the User's role membership, their password appears to be reset to the initial value when the resource was created.
To Reproduce Steps to reproduce the behavior:
- Create a new User resource with a default hashed password of "password"
- Get the user to update their password once they login for the first time
- Update a User's role membership in the Terraform template
- After the update, the User's password has reverted to the initial value of "password"
Expected behavior I would expect Terraform to use the "password" or "hashed_password" only on resource creation but ignore the value on subsequent updates. I don't want to have to keep telling users to reset their passwords on every role/application change.
@PBarnard - I believe this may be more linked to the behaviour of terraform as opposed to the specific provider. If the hashed password is being stored in state then when you run a TF Plan it will compare the value in state against the infrastructure and revert anything that has not been applied via IaC. If you can try running the above steps but without step 3 and instead just rerun a TF apply based on the original config then it will probably still change this back to the previous value anyway (given the above is correct).
One way you could potentially get around this is to use a lifecycle block (https://www.terraform.io/language/meta-arguments/lifecycle - more specifically ignore_changes within this), against the value of password, when creating the resource in Terraform. This will effectively cause terraform to not care what this is being set as.
It's worth noting however that this behaviour is by best practice and design of Terraform. If you are creating and managing a resource via terraform then any changes to this should be made via code to ensure you have an idempotent solution and that your terraform state is a direct representation of your infrastructure. 👍
Thanks for the feedback @RobsonSutton I'll definitely have a look into the ignore_changes lifecycle as you suggested.
It's worth mentioning though that I don't think you can retrieve a User's password via the API; If I do a GET against security/user/username then password isn't returned, as such, it's not possible for Terraform to compare the password set on creation against the current password (whatever it may be).
It's similar to Terraform creation of an AWS RDS database, you can specify the database password at creation time in the Terraform template, but if you use the AWS Console to update the password, subsequent changes to RDS properties in the Terraform template do not revert the password back to the original value (stored in state).
Never having written a TF Provider myself I'm not sure of the technicalities of doing so but based on the behaviour of the AWS RDS Provider, it must be possible to have Terraform ignore a specific property on subsequent updates.
Issue raised against the RDS Provider about password retrieval - https://github.com/terraform-aws-modules/terraform-aws-rds/issues/234
@PBarnard - That makes sense! Apologies, am new to provider dev and probably should have actually looked at the code and docs first...!
Can see that your expectation of the behaviour is reinforced by the docs here: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-user.html
I have raised a PR but haven't had a chance to test yet, hopefully will have some time this evening to take a look again for you 👍
Great! Thanks @RobsonSutton 😄
Closed by https://github.com/elastic/terraform-provider-elasticstack/pull/128