Write-Only UI Editing #31601
Description
Is your feature request related to a problem? Please describe.
I found it quite annoying that I cannot get the UI to correctly show write-only secrets. The goal is to allow users to update or rotate a secret in the UI without being able to read or copy the secret's current value (which for us is a vulnerability, as it allows users to bypass audits).
If we grant read, the "Edit secret" button works, but the "View secret" (eye icon) and "Copy secret" buttons also become active. This violates our security model and allows for secret exfiltration.
If we deny read, the "View" and "Copy" buttons are correctly disabled, but the "Edit secret" button also disappears, preventing users from updating the secret via the UI.
This forces us to enforce CLI use, which is not user-friendly to ensure security.
Describe the solution you'd like
I would like the "Edit secret" functionality in the UI to be decoupled from the read capability.
A user with only create or update capabilities on a KV path (but no read capability) should see an enabled "Edit secret" button.
When this button is clicked, the UI should open the "Edit secret" modal with blank key/value fields. This would allow the user to perform a "blind overwrite" of the secret (similar to how GitHub secrets work), creating a new version without ever seeing the data from the previous version.
Additional context
Enforcing "Set-and-Forget" Model: This feature would allow an organization to properly enforce a "set-and-forget" security model for human-driven workflows, not just for machines.