I have a multiple index system where some roles can search some indexes and other roles other indexes. My personal user has several roles with access to multiple indexes. There are enough of them that I sometimes want to review the list for reference.
Is there a search or some other nice way to the list of indexes I am allowed to search?
I guess that going into the manager is not the answer you want. 🙂
| rest /services/admin/roles | table title, srchIndexesAllowed | rename title as role
could be what you want? I don't think very restricted roles can perform this search, but the ordinary
user role can find out it's permissions.
I'll do one better, I do this everyday, so when I have to check I can just
"|inputlookup user_authorizations.csv | search username=$USER". This might not work if you don't have permissions on the endpoints.
| rest /services/authentication/users
| rename title AS username roles AS role
| mvexpand role
| fields realname username role
| join type=outer role [
| rename title AS role | eval indexes=mvjoin(srchIndexesAllowed," ; ")
| fields role indexes]
| table realname username role indexes | outputlookup user_authorizations.csv
please accept the answer that has answered your question most completely.
For a specific user, the easiest and fastest is:
| eventcount summarize=f index=_* index=* | stats count by index
Every user can run this from search, so you don't need access to rest. On the other hand, you can't get this information for another user using this method. It will include indexes that are empty as well.
How do you get this search to work?
I'm running Splunk 5.0.2 as admin and when I run this search it yields No Results.
I enter it exactly as is in the search bar. It has worked for me in every version from 4.1 or so till now.
And just to be clear, the
eventcount command does not require any special permissions. It is the same command that was used on the Splunk 4.x and 5.x pages to display the total numbers of events on the search app overview page.
Thanks, I guess I figured the pipe in the beginning was assuming a preceding string. It was much faster than my search.
For my purposes this seems like the simplest and it is very quick to return. Thanks! @gkanapathy