## Problem Non-CI/CD secret access (#594090) adds a new `read_value` permission to the secrets permission model so a principal can read a secret's actual value (not just its metadata). The backend wiring lands in #594090, but users cannot grant the new permission until the UI exposes it. Until then, the access-token endpoint works at the backend / API level but is not usable in practice, because there is no way for an Owner to grant `read_value` through the UI. ## Background: how UI permissions map to OpenBao Each permission row a user sets for a principal becomes an ACL policy in OpenBao. Each option toggles a capability on a path. There are two paths: a metadata path and a value (data) path. The metadata-vs-value distinction is exactly which path the read capability lands on. | UI permission | Action (model) | OpenBao capability | Path | |---|---|---|---| | Read metadata (today's "Read") | `read_metadata` | `read` | metadata path | | Write | `write` | `create` + `update` | value path | | Delete | `delete` | `delete` | value path | | **Read value (new)** | `read_value` | `read` | value path | ## Proposal 1. Expose the new `read_value` action in the secrets permission GraphQL mutations and types (permissions enum, create/update permission, permission type). 2. Add a "Read value" option to the secrets permission UI, for the same principal types already supported: a specific User, a Role (Reporter and up), a custom Member Role, or a Group. 3. Clarify the labeling so "Read value" (the actual secret value) is clearly distinct from the existing read-metadata permission. Coordinate the exact wording with technical writing. Today's "Read" should be relabeled to "Read metadata". 4. Enforce in the UI that "Read value" requires read-metadata (you cannot read a value for a secret you cannot otherwise see). Additive, not a replacement. ## Permission action transition (`read` -> `read_metadata`) The backend MR (#594090) lands the action change additively, so it can ship first without a lockstep deploy: - Backend accepts both `read` and `read_metadata` on input (aliases, both mean read-on-metadata-path). - Backend readback keeps emitting `read` for now, so the current UI is untouched. - Backend adds `read_value`. This frontend MR completes the migration (FE and BE ship together, so the deprecation removal happens here, not a separate follow-up): - Send and display `read_metadata` instead of `read`. - Add `read_value` handling. - Remove the deprecated `read`: stop sending it, flip backend readback to emit `read_metadata`, and drop the `read` input alias. ## Scope - In scope: GraphQL exposure of `read_value`, the secrets permission UI changes, and completing the `read` -> `read_metadata` migration (including removing the deprecated `read` alias). - Out of scope: the permission model, OpenBao policy wiring, the auth role, and the endpoint (all in #594090). This issue does not block #594090 from merging; it makes the feature usable for end users. ## Related - #594090 (endpoint + backend wiring, where `read_value` and the `read_metadata` alias are defined)