Skip to content

Conversation

@cHiv0rz
Copy link

@cHiv0rz cHiv0rz commented Oct 31, 2025

Description

This PR fixes an issue where creating a secret in the Vault UI with an empty key field results in a secret with an empty string as the key ("": "value"), which causes problems when accessing the secret from Kubernetes and other clients.

What

When a user enters a value in the secret data section but leaves the key field empty (showing the "key" placeholder), the system now defaults the key to "key" (or the custom placeholder text if specified) instead of using an empty string.

Why

Empty string keys are problematic in many scenarios:

  • When using VaultSecretsOperator, Kubernetes cannot properly access secrets with empty string keys.
  • It's not intuitive that leaving the key field empty would create an empty string key rather than using the suggested placeholder.
  • The placeholder text "key" suggests that this would be the default if left empty.

How

The fix modifies the KVObject utility class to:

  1. Accept an optional defaultKey parameter in the toJSON and toJSONString methods.
  2. Use the defaultKey (defaults to 'key') when a key is empty but the value is not empty.
  3. Preserve existing behavior for empty keys with empty values (they are excluded).

The KvObjectEditor component was updated to pass the placeholder key value when calling toJSON, ensuring that custom placeholders are respected.

Changes

  • Core Logic: app/lib/kv-object.js

    • Added defaultKey parameter to toJSON method.
    • Modified logic to use defaultKey when key is empty and value is not empty.
    • Updated toJSONString to propagate the parameter.
  • UI Component: lib/core/addon/components/kv-object-editor.js

    • Updated updateRow and deleteRow actions to pass placeholder key to toJSON.
  • Tests:

    • Added unit tests in tests/unit/lib/kv-object-test.js.
    • Added integration tests in tests/integration/components/kv-object-editor-test.js.

Testing

Unit Tests

  • Verified that empty keys with values default to "key".
  • Verified that custom default keys work correctly.
  • Verified that empty keys with empty values are still excluded.

Integration Tests

  • Verified that the KvObjectEditor component uses "key" as the default.
  • Verified that custom placeholders are used as the default key.

Manual Testing Steps

  1. Navigate to the Vault UI.
  2. Go to a KV v2 secrets engine.
  3. Click "Create secret".
  4. Enter a path (e.g., test/mysecret).
  5. In the secret data section, leave the key field empty and enter a value.
  6. Click "Save".
  7. Verify the secret has a key named "key" with the entered value.
  8. Verify the secret can be accessed from Kubernetes/API using secret.data.key.

Backward Compatibility

The changes are fully backward compatible:

  • Empty keys with empty values are still excluded (existing behavior).
  • The defaultKey parameter has a default value, so existing code continues to work.
  • No breaking changes to any APIs or components.

Screenshots

Before

Creating a secret with empty key resulted in:

{
  "": "myvalue"
}

After

Creating a secret with empty key now results in:

{
  "key": "myvalue"
}

@cHiv0rz cHiv0rz requested a review from a team as a code owner October 31, 2025 16:44
@vercel
Copy link

vercel bot commented Oct 31, 2025

@cHiv0rz is attempting to deploy a commit to the HashiCorp Team on Vercel.

A member of the Team first needs to authorize it.

@hashicorp-cla-app
Copy link

hashicorp-cla-app bot commented Oct 31, 2025

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant