Add write-only password support to elasticsearch_security_user resource

[Copilot]

Migration Plan: elasticsearch_security_user to Plugin Framework + Write-Only Attributes

Phase 1: Migrate from SDKv2 to Plugin Framework ✅

• Create new directory structure: internal/elasticsearch/security/user/
• Create Plugin Framework files following system_user pattern
• Move acceptance tests from user_test.go to user/acc_test.go
• Add TestAccResourceSecurityUserFromSDK test for seamless migration
• Register new resource in provider/plugin_framework.go
• Remove old SDKv2 resource registration from provider/provider.go
• Create user_shared.go for data source compatibility
• Delete old user.go and user_test.go files
• Run acceptance tests to verify migration
• Commit Phase 1 changes

Phase 2: Add Write-Only Attribute Support ✅

• Add password_wo and password_wo_version attributes to schema
• Update create/update logic to handle password_wo and password_wo_version
• Add TestAccResourceSecurityUserWithPasswordWo acceptance test
• Run all tests to verify functionality - all tests passing
• Run linting and documentation generation
• Address code review feedback
• Commit Phase 2 changes

Phase 3: Address PR Review Feedback ✅

• Simplify resource-description.md to just the description
• Use built-in ConflictsWith, PreferWriteOnlyAttribute, and AlsoRequires validators
• Add SizeAtLeast(1) validator for roles
• Add type assertions for resource interfaces
• Remove redundant return in create.go
• Simplify state checking logic in update.go
• Fix password_wo version change detection logic
• Update PutUser and DeleteUser to return Framework diagnostics directly
• Remove custom validators.go file
• Read password_wo from config instead of plan (per Terraform write-only guidelines)
• Fix Go formatting issues
• All tests passing (4/4)

Summary

Successfully migrated elasticsearch_security_user resource from Terraform SDKv2 to Plugin Framework and added write-only password support for ephemeral resources.

Key Features:

1. Seamless Migration: Existing SDKv2 resources can be upgraded to the new Plugin Framework version without recreation
2. Write-Only Password Support: New password_wo and password_wo_version attributes allow using ephemeral resources (like Vault secrets) without storing passwords in state
3. Built-in Validators: Uses Terraform's built-in validators for better maintainability
4. Framework Diagnostics: Direct use of Framework diagnostics in PutUser and DeleteUser functions
5. Proper Write-Only Implementation: Follows Terraform's guidelines by reading password_wo from config rather than plan

Testing:

• All acceptance tests passing (4/4)
• SDK to Framework migration test validates seamless upgrade
• Write-only password test validates create and update flows with version-based change detection
• Import test validates password change detection works correctly

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Feature] Add write-only argument support for resources like elasticsearch_security_user</issue_title>
<issue_description>Is your feature request related to a problem? Please describe.

When creating an elasticsearch_security_user, I have to provide a password right now through a normal field. If I want to source the password from an ephemeral resource (such as HCP Vault's kv_secret_v2.

The kv_secret_v2 data source is not the suggested path anymore (when possible), as it causes secret leakage into your statefile.

Also, the data source is considered deprecated when you try to use it (Output from my terminal appended below):

│ Warning: Deprecated Resource
│ 
│   with data.vault_kv_secret_v2.elastic,
│   on data.tf line 6, in data "vault_kv_secret_v2" "elastic":
│    6: data "vault_kv_secret_v2" "elastic" {
│ 
│ Deprecated. Please use new Ephemeral KVV2 Secret resource `vault_kv_secret_v2` instead
│ 
│ (and one more similar warning elsewhere)

Describe the resource you would like to have implemented.

elasticsearch_security_user and any other resource which accepts sensitive values should have a corresponding write-only argument option for the sensitive value.

Describe the solution you'd like

For something like elasticsearch_security_user, two new fields should be added:

• password_wo: Accepts the ephemeral resource value
• password_wo_version: Field used to trigger an update of the resource, rather than triggering off the secret value changing. This could also be a string field where the suggestion is to strongly hash the password, so it would update only whenever the value actually changes. An example using an integer is present in the aws_db_instance resource

Describe alternatives you've considered

Continuing to use data sources...but this is the state of things now and does not solve the issue of secrets ending up in a statefile

Additional context

• Terraform docs on ephemeral resources: https://developer.hashicorp.com/terraform/language/manage-sensitive-data/ephemeral
• Vault provider docs on ephemeral resources: https://registry.terraform.io/providers/hashicorp/vault/latest/docs/guides/using_ephemeral_resources#use-the-vault-providers-new-ephemeral-resources
• OpenTofu has implemented the ephemeral resource API and is just doing output format cleanup now: RFC tracker: Ephemeral resources and write-only arguments opentofu/opentofu#2834</issue_description>

<agent_instructions>Add a new write-only password_wo and password_wo_version attribute to the elasticsearch_security_user resource.

A validator should be added to the password_wo and password attributes ensuring only one of them can be set.
The password_wo_version attribute should only be allowed to be set if password_wo is also set.
The PreferWriteOnlyAttribute validator should be added to the existing password attribute.
An acceptance test should be added validating create and update flows with the new password_wo attribute.
Make sure you always follow the copilot instructions </agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [Feature] Add write-only argument support for resources like elasticsearch_security_user #1295
• Related to Migrate stack provider to newer TF framework #1214

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

@copilot can you address all the PR comments.

All PR review comments have been addressed. Latest commit: 4832692

[Copilot]

@copilot address the PR comment.

PR comment addressed. Commit: 25b0fb7

[tobio]

@copilot make lint is failing because of unformatted Go files. Can you fix up the formatting and commit the result.

[Copilot]

@copilot make lint is failing because of unformatted Go files. Can you fix up the formatting and commit the result.

Fixed Go formatting by removing trailing whitespace. make lint now passes. Commit: 599ce14

[dimuon]

nit-pick: While the current approach works, I think having separate Create and Update implementations would be simpler. Maybe we can adjust the Copilot rules to enforce this.

[dimuon]

Besides a few nit-picks and one missing check for nil, LGTM.