Cypher policy/access for a "read only" like current "Full Decrypt" in 6.0.2

[rjr162]

Headline:
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

---

Description:
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.

---

Example/Use case(s):
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.

---

[sjabro]

Hi @rjr162,

We have the Cypher Access policy which I believe will get you where you are looking to go. These are configured at Administration → Policies and can be scoped to users & roles.
Cypher Policies — Morpheus Docs documentation (morpheusdata.com)

We have also put out a video on this capability on our YouTube channel.
Implementing Cypher Access Policies - YouTube

[rjr162]

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.

[sjabro]

I will take your use case and work through it.

1. Bob logs in and his role is mapped to the user account. This role would have Full Decrypted enabled for Cypher.
2. A cypher access policy is in place that is scoped to that role using the key path "secret/bobs_role/.*. This role has READ and LIST enabled on it.
   
   
3. Bob provisions an instance, during which a workflow task runs that creates a secret named “secret/bobs_role/bobs_admin_password”
4. After the instance is provisioned, Bob is able to go to the Cypher tab and see his Cypher secret.
   
   
5. Bob is able to decrypt this secret
   
   
   
   but if he tries to remove the secret, he will be met with the following error.
   
   and if he tries to create a Cypher secret
   
   

This policy removes the ability for Bob to see any other secrets that are not within that initial path.

Caveat:

Anyone in that role will have the same policy applied to them.

EXAMPLE:

1. Jim is in Bob’s Role and deploys an instance
2. The workflow creates a Cypher secret call “secret/bobs_role/jims_admin_password”
3. Both Bob and Jim can list and decrypt both of the Cypher secrets because they are within the path of “secret/bobs_role/.*”
   
   

[rjr162]

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!

Thanks!