Hi,
I have an app which allows to send custom alerts to an external provider.
Recently the app uses secret storage to:
1) Store/save keys during setup view
2) Read the key on Python alert script to invoke the external provider
Because any "common" user is able to create an Alert, during the executing I'm seeing an error reading the key due to the lack of "list_storage_passwords" role
Questions:
- Is this role required for all users that setup this Alert that read the App secret key?
- I've have some concerns from administrators saying they don't want to give out this role as it implies allowing these users to read ALL secrets from the Splunk instance. Is this accurate? Or this list_storage_passwords role will actually only allow reading specific App secrets that are marked as read for all users?
Thank you.
My understanding is that credentials created by POST request to the `storage/passwords` endpoint end up encrypted in `passwords.conf`, where they are treated like any other knowledge object. By default they will be accessible to any user with the `admin_all_objects` or `list_storage_passwords` capabilities, but you should be able to perform more granular access control via `metadata/local.meta` like with any other knowledge object in Splunk. This would allow admins to lock down access to specific credentials with more specificity (or, if you're building this app yourself, you could use the app's setup page where configuration is performed to complete this additional step).
I believe that this app includes functionality for managing permissions on existing secrets as described above: REST storage/passwords Manager for Splunk
This is an area where I feel Splunk is severely lacking.
It would be great if there was a mechanism for sharing one password with a group of users without having to give out list_storage_passwords, then retroactively update all of our apps to limit access. We have custom SPL commands that require passwords to be entered on a setup screen. We cannot give everyone list_storage_passwords, so the ability to use these commands is limited to our admins.
Edit: Just saw the ideas links. Added my Vote.
Right, I have to say I agree with you there and would recommend voting on these Ideas in order to raise awareness of the limitation.
e: to expand on that - the issue with even the solution I mentioned is that you would need to retroactively apply the *.meta access control approach to each existing and future secret on your deployment in order to actually address the use case in the OP.
@mmmarchman , @daps - This is currently how Splunk is designed. But others also requested to allow granular access to Splunk stored passwords. You can find them on ideas.splunk.com and upvote them if you like Splunk to implement them in the future.
I hope this helps you understand the issue that Administrators are facing here.!!
Can we please get a response to this question? We are running into this same issue/questions with our App and need to respond to customers appropriately. Thank You.