- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm trying to restrict the metadata that is available to users of a particular role. The main reason I'm doing this is because I don't want users to be able to see tons of information about different hosts/sources/sourcetypes that they cannot access while they are in the dashboard, but I do want them to be able to see the information about the hosts/sources/sourcetypes that are available to them. Is there a way to restrict the metadata to just what the user is allowed to access?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as i know (and the little test that i just concluded) there is no way to tell the role what metadata to show and what not to show.
However, i believe what you are trying to achieve can be done by the following:
- Create a role that does not have access to the main index
This role will have only these capabilities:
- change_own_password
- get_metadata
- get_typeahead
- list_inputs
- request_remote_tok
- rest_apps_view
- rest_properties_get
- rest_properties_set
- search
This role will not inherit any other capabilities from any other role (ie. remove the user from the selected roles list)
- Create a user and assign it to this role
- Assign data that you want this role to see to the index that you specified for the role
- Logout from your admin user and login with the newly created user (belonging to the newly created role)
- Check to see if you see other metadata or if you only see the metadata that belong to this index.
Here is my setup:
Created an index called localping.
used ping localhost > meta.test to get some sample logs.
Created a new role called metadatatest and gave it the above capabilities and made localping the default index as well as the only index that this role can search
Created a user called metauser with the metadatatest role.
Logged in with this user and can only see info from the localping index.
Here is a sample screenshot:
Sources (1) Source | Total Count | Last Updated (desc)
* /Users/gzaimi/meta.test | 1,283
Sourcetypes (1) Sourcetype | Total Count | Last Updated (desc)
* test-too_small | 1,283
Hosts (1) Host | Total Count | Last Updated (desc)
* localhost | 1,283
As you can see i can only see these instead of seeing a lot more data that i can usually see with the admin role.
Hope this helped.
.gz
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is related and should generalize...
I populate sideview pulldowns with a list of HPC clusters, each saved into an index with an hpc_ prefix. The below forms the list of all such indexes, and then subsets it to only those the user's role allows them to search (determined by the role's allowed index list).
| eventcount summarize=false index=hpc_* | where count>0 | map [search index=$index$ | head 1] maxsearches=20 | eval cluster=substr(index,5) | fields cluster
Perhaps you could form lists of hosts/sources/sourcetypes via |metadata
and then subset via map
according to role search filters?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
disclaimer: the above is slow with many indexes (no surprise), and splunk5's eventcount appears to only list those indexes permitted by the current role, so map is unnecessary.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually when i tried it with just the index it did not work completely, ie. it did show me the rest of the info which is in the main index. - hence the removing of the user role privileges and creating the role with only the given capabilities.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as i know (and the little test that i just concluded) there is no way to tell the role what metadata to show and what not to show.
However, i believe what you are trying to achieve can be done by the following:
- Create a role that does not have access to the main index
This role will have only these capabilities:
- change_own_password
- get_metadata
- get_typeahead
- list_inputs
- request_remote_tok
- rest_apps_view
- rest_properties_get
- rest_properties_set
- search
This role will not inherit any other capabilities from any other role (ie. remove the user from the selected roles list)
- Create a user and assign it to this role
- Assign data that you want this role to see to the index that you specified for the role
- Logout from your admin user and login with the newly created user (belonging to the newly created role)
- Check to see if you see other metadata or if you only see the metadata that belong to this index.
Here is my setup:
Created an index called localping.
used ping localhost > meta.test to get some sample logs.
Created a new role called metadatatest and gave it the above capabilities and made localping the default index as well as the only index that this role can search
Created a user called metauser with the metadatatest role.
Logged in with this user and can only see info from the localping index.
Here is a sample screenshot:
Sources (1) Source | Total Count | Last Updated (desc)
* /Users/gzaimi/meta.test | 1,283
Sourcetypes (1) Sourcetype | Total Count | Last Updated (desc)
* test-too_small | 1,283
Hosts (1) Host | Total Count | Last Updated (desc)
* localhost | 1,283
As you can see i can only see these instead of seeing a lot more data that i can usually see with the admin role.
Hope this helped.
.gz
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Index wise, you should be able to restrict the metadata. I'm not completely sure about your particular application and would like to see the specific role filters.