Add support for ephemeral vault_token resource with type and entity_alias fields

[Siddharth-Kannan]

Description

Created new ephemeral resource for resource_token and added support for type and entity_alias fields.
Added acceptance tests for the ephemeral resource.
Added a deprecation message for the sdkv2 implementation of the token resource.

Performed testing across vault versions 1.15.0-1.21.0

Checklist

• Added CHANGELOG entry (only for user-facing changes)
• Acceptance tests where run against all supported Vault Versions

Output from acceptance testing:

$ terraform-provider-vault % go test -v -count=1 -run TestAccToken ./internal/vault/auth/ephemeral/
=== RUN   TestAccToken_basic
--- PASS: TestAccToken_basic (2.83s)
=== RUN   TestAccToken_batch
--- PASS: TestAccToken_batch (1.31s)
=== RUN   TestAccToken_withPolicies
--- PASS: TestAccToken_withPolicies (3.09s)
=== RUN   TestAccToken_orphan
--- PASS: TestAccToken_orphan (2.97s)
=== RUN   TestAccToken_withRole
--- PASS: TestAccToken_withRole (3.64s)
=== RUN   TestAccToken_wrapped
--- PASS: TestAccToken_wrapped (3.97s)
=== RUN   TestAccToken_wrappedBatch
--- PASS: TestAccToken_wrappedBatch (2.58s)
=== RUN   TestAccToken_withEntityAlias
--- PASS: TestAccToken_withEntityAlias (4.13s)
=== RUN   TestAccToken_batchTokenAutoDetectionViaRole
--- PASS: TestAccToken_batchTokenAutoDetectionViaRole (2.11s)
=== RUN   TestAccToken_full
--- PASS: TestAccToken_full (2.88s)
PASS
ok      github.com/hashicorp/terraform-provider-vault/internal/vault/auth/ephemeral     30.430s
...

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[Copilot]

Pull request overview

This PR introduces a Terraform Plugin Framework ephemeral vault_token resource to create Vault tokens with automatic revocation, expands functionality (token type + entity_alias), adds acceptance coverage, and deprecates the legacy SDKv2 vault_token resource to guide users to the more secure ephemeral approach.

Changes:

• Added new ephemeral "vault_token" implementation with token creation + best-effort cleanup on Close().
• Added acceptance tests for the new ephemeral token behavior (service/batch/role/wrapping/entity alias scenarios).
• Added deprecation messaging to the legacy SDKv2 vault_token resource and documented the feature in the changelog.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
vault/resource_token.go	Adds deprecation message steering users from SDKv2 resource to the new ephemeral resource.
internal/vault/auth/ephemeral/token.go	New ephemeral vault_token resource implementation (schema, Open/Create, Close/Revoke).
internal/vault/auth/ephemeral/token_test.go	New acceptance tests using echo provider state checks for ephemeral outputs.
internal/provider/fwprovider/provider.go	Registers the new ephemeral token resource in the framework provider.
internal/consts/consts.go	Adds FieldEntityAlias constant used by the new ephemeral resource/tests.
CHANGELOG.md	Documents the new ephemeral resource and the legacy resource deprecation note.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[siyer-corp]

Should we add an else block here?

[Siddharth-Kannan]

No, we don't need to add an else block. After verifying the Vault response model, I confirmed that wrapped token responses do not contain an auth object, and token_policies, entity_id, or orphan fields. These fields are marked as Computed: true in the schema, which means they default to null values when not explicitly set. Adding an else block to explicitly set them to null would be redundant.

Additionally, I've added test coverage to verify this behaviour - the tests confirm that these fields are properly null for wrapped tokens without requiring explicit initialisation.