Boundary: awskms kms_key_id with env:/// URIs passed literal (NotFoundException)

[azman0101]

Describe the bug
When configuring a worker with KMS stanza, using env://BOUNDARY_KMS_KEY_ID or file:// URIs in the kms_key_id field of the kms "awskms" block results in a failure. Boundary appears to pass the literal URI string to AWS KMS instead of resolving it to the actual key ID value.

To Reproduce
Steps to reproduce the behavior:

1. Set up a worker HCL with:

   kms "awskms" {
     kms_key_id = "env://BOUNDARY_KMS_KEY_ID"
     purpose    = "worker-auth"
   }

2. Provide the environment variable via systemd EnvironmentFile or shell.
3. Start the worker using boundary server -config=...
4. Observe the error:

   NotFoundException: Invalid keyId 'env://BOUNDARY_KMS_KEY_ID'
   

Expected behavior
Boundary should resolve env://BOUNDARY_KMS_KEY_ID to the actual environment variable value before passing it to the AWS KMS plugin. Similarly, file:// URIs should be read and parsed before invocation.

Note: AWSKMS_WRAPPER_KEY_ID workaround

A practical workaround that does work is to set the environment variable AWSKMS_WRAPPER_KEY_ID and let the awskms plugin read the key ID from that env var. This bypasses the env:// or file:// URI resolution path and the plugin accepts the key id directly.

However, this approach has an important limitation: AWSKMS_WRAPPER_KEY_ID is a single, global environment variable. If you set it, every awskms stanza that relies on that mechanism will use the same KMS key ID. That prevents using multiple KMS keys for different purposes (for example, root, worker-auth, and recovery) simultaneously.

Additional context

• Boundary version: v0.20.1
• Running on AL2 with systemd
• Environment variables are correctly loaded and visible to the process
• Using KMS documentation here

[johanbrandhorst]

Thanks for your issue. I did a bit of digging and I think the logic for this configuration field is here: https://github.com/hashicorp/go-kms-wrapping/blob/7f7ab88e5089cee676748105a76819567812d45b/wrappers/awskms/options.go#L62-L63. This plugin logic is shared with Vault so it might not be as easy as just calling parseutil.ParsePath here (and then again, it might). Which other fields do you think need to support this?