Only superusers can decrypt a secret #3954

Closed
opened 2025-12-29 18:32:15 +01:00 by adam · 2 comments
Owner

Originally created by @Dimaqa on GitHub (Aug 7, 2020).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.9-beta2

Steps to Reproduce

This was mentioned log ago in #2869

  1. Create user and give him all secret permissions
    i.e (secret, secret role, user key, session key) | (view, add, change, delete)
  2. Activate user key
  3. Check that that you have active session key
  4. On secret page there is message You do not have permission to decrypt this secret.
  5. From api empty plaintext field received
  6. As soon as you give this user Superuser status he can decrypt secrets

Expected Behavior

After getting session key it should be possible to view secret text

Observed Behavior

Only superusers can decrypt secrets

Originally created by @Dimaqa on GitHub (Aug 7, 2020). ### Environment * Python version: 3.6.8 * NetBox version: 2.9-beta2 ### Steps to Reproduce This was mentioned log ago in #2869 1. Create user and give him all secret permissions i.e (secret, secret role, user key, session key) | (view, add, change, delete) 2. Activate user key 3. Check that that you have active session key 4. On secret page there is message **You do not have permission to decrypt this secret.** 5. From api empty plaintext field received 6. As soon as you give this user Superuser status he can decrypt secrets ### Expected Behavior After getting session key it should be possible to view secret text ### Observed Behavior Only superusers can decrypt secrets
adam added the type: bugbeta labels 2025-12-29 18:32:15 +01:00
adam closed this issue 2025-12-29 18:32:16 +01:00
Author
Owner

@jeremystretch commented on GitHub (Aug 7, 2020):

NetBox version: 2.9-beta2

Please specify your current NetBox version. (There is no beta2 release currently.)

@jeremystretch commented on GitHub (Aug 7, 2020): > NetBox version: 2.9-beta2 Please specify your current NetBox version. (There is no beta2 release currently.)
Author
Owner

@jeremystretch commented on GitHub (Aug 7, 2020):

This behavior is expected if you have not added the user (or an assigned group) to the secret's role. Prior to the implementation of object-based permissions (#554), role assignment was used to restrict a user's access to secrets.

With the assumption that this behavior is adequately explained, I'm going to close this bug report. (If not, please ask that it be reopened.) However, I've also raised #4969 to discuss deprecating the use of secret roles for access control, as the mechanism is no longer needed.

@jeremystretch commented on GitHub (Aug 7, 2020): This behavior is expected if you have not added the user (or an assigned group) to the secret's role. Prior to the implementation of object-based permissions (#554), role assignment was used to restrict a user's access to secrets. With the assumption that this behavior is adequately explained, I'm going to close this bug report. (If not, please ask that it be reopened.) However, I've also raised #4969 to discuss deprecating the use of secret roles for access control, as the mechanism is no longer needed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3954