Introduce a “Cypher Role Access” setting that’s like the “Full Decrypt” or “Read” but one that allows a user to decrypt a secret they have access to but block any other access such as create new and deleted
It would be extremely useful to have a Cypher Role access that’s similiar to the “Fully Decrypt” in 6.0.2 but that ONLY allows decrypt. Using the current Policy feature for Cypher with it’s filter, and the Role permissions, it almost gets us to a long after feature request of providing a method for users to have limited/restricted access to specific Cypher secrets without the ability to adjust, delete, or create new. This feature would be amazingly helpful for when you have disparate groups within a single Tenant as you can control the RBAC to specific Cypher entries related to only their roll mappings.
Use “Bob” logs in and is mapped roles via the SAML group memberships.
Bob creates an instance where part of the workflow stores a ‘root’ or ‘administrator’ password in Cypher, either one entered by Bob at provision time or a randomly generated one created during the provisioning process.
Password is stored in Cypher in the formation of secret/role_name/instance-name_root or the like
Bob’s related role has a “Read Decrypt” privilege access to Cypher
There is a policy in place that limits the “role_name” Role to Cyphers with the pattern ‘secret/role_name/.*’
Bob is now able to view the Cypher entries related to his role/instances without seeing other units, and without having the ability to delete the entry or create new cypher objects.
Bonus points if the there was also maybe a “Edit Decrypt” that would allow editing of the password value but no other aspects of the Cypher entry.
Unfortunately, from my testing, the Role Permissions for “Read”, “User”, and “Full” sort of work (but potentially with more access than just “read”), but none list the “Decrypt” button outside of “Full Decrypt”. The others will just list the Cypher as existing but nothing more in the WebUI, at least in cases where another user created the entry.
For the people in the same role having the same access to all of the related things, that’s perfect and what I’m looking for.
In terms of the other aspects, I confirmed I’m seeing what you’re describing. I guess from a UI/UX perspective it’s a bit confusing at first in terms of the options you don’t have access to be displayed and then denying vs just being hidden, BUT with that said this is something that does fit my use case overall and so I’d say the idea is already implemented!