(seen also in this comment https://github.com/netbox-community/netbox/issues/2869#issuecomment-584106870 on closed ticket )
step 4 : unlock button is green and permit to add private key to session then see password
step 6 : unlock button is green and permit to add private key to session then see password
step 4 : unlock button is stil grey and permission deny message when try to use it
step 6 : we've got warning message : "you do not have permission to view secret"
The fact that we can see secret in step 8 is also an issue as the permission should works exactly the same way in any view.
Best regards,
Al
The root issue here is that secret role assignment is not being enforced on API calls. When you create a secret, it must be assigned to a role. This role is assigned certain users and/or groups which have permission to decrypt the secrets belonging to it. Users which don't belong to the role should not be able to decrypt the secret.
Everything above is correct until step eight: The user should not be given the option to decrypt the secret, assuming he has not been assigned to the secret's role. Further, decryption via the API should fail, and it currently does not.
We'll need to take measures to ensure that
1) The UI displays the "unlock" button only if the user belongs to the secret's role, and
2) Secrets retrieved via the API are decrypted _only_ if the user belongs to the secret's role.
This answer is awesome.
It's permit me to find how to manage access to some passwords and not the other one. I was searching for it and just found how to : edit secret role, i did not find it previously.
Thanks!
Most helpful comment
The root issue here is that secret role assignment is not being enforced on API calls. When you create a secret, it must be assigned to a role. This role is assigned certain users and/or groups which have permission to decrypt the secrets belonging to it. Users which don't belong to the role should not be able to decrypt the secret.
Everything above is correct until step eight: The user should not be given the option to decrypt the secret, assuming he has not been assigned to the secret's role. Further, decryption via the API should fail, and it currently does not.
We'll need to take measures to ensure that
1) The UI displays the "unlock" button only if the user belongs to the secret's role, and
2) Secrets retrieved via the API are decrypted _only_ if the user belongs to the secret's role.