Security

Access Control: What is the best approach to limiting users to specific Apps or Views?

Builder

We have a fairly large deployment with 60 plus individual apps. These are used almost exclusively by DEVOPS and we haven't really had a need to limit users from using apps/views.

Now we have a need to expose some data to 200 people outside of IT and would like to determine the best way to prevent them from being able to just poke around... i.e. limit them to a specific APP and/or Views/Dashboards within that app and not allow them access to Search within that app.

Based on docs, to grant a role only access a single App it looks like I need to:

  1. Remove "everyone" access from all apps and grant each existing role specific access to all 60+ existing apps
  2. Create a new role with most capabilities of user (e.g. user_external)
  3. Grant user_external access only to the apps/views needed

Do I have this right? If so any suggestions as to the best way to go about it?

For background, I am power user/developer without full admin access who just got admin certification. I will be bringing approaches to the Splunk admin team to execute and want to bring best practice to the table as we haven't done this before.

Thanks!

0 Karma
1 Solution

Esteemed Legend

There are 2 types of restrictions with Splunk's RBA: access to indices and access to commands. You should create your new roles along these lines. In your case, you have only 2 types of users so you might as well just create a custom role for the new type and do not inherit from any other role. If you will end up having many types of users, it would bet better to create "stackable" roles (like the can_delete role) to create an inheritance structure.

View solution in original post

0 Karma

Esteemed Legend

There are 2 types of restrictions with Splunk's RBA: access to indices and access to commands. You should create your new roles along these lines. In your case, you have only 2 types of users so you might as well just create a custom role for the new type and do not inherit from any other role. If you will end up having many types of users, it would bet better to create "stackable" roles (like the can_delete role) to create an inheritance structure.

View solution in original post

0 Karma

SplunkTrust
SplunkTrust

Assuming your data is segregated into different indexes, I would create a new role which would restrict the users ability from seeing options in the User Interface.

0 Karma

Builder

PS... I am planning on giving them only a simple dashboard to access data, not open search access to I am more interested in controlling access that way. I am not planning on giving them access to search and reporting, etc.

0 Karma

SplunkTrust
SplunkTrust

Hi snoobzilla,
the most important thing is to associate to external_users role only the correct indexes, because Splunk gives data Access Rights to roles.
In addition remember to give the new role to all the App's objects (fields, tags, ...).

Bye.
Giuseppe

0 Karma

Builder

See above. I would like to restrict more based on what they can see from an interface standpoint than a data standpoint.

0 Karma

SplunkTrust
SplunkTrust

If you don't give access for a role to an index, the role cannot see the index.
With grants to the dashboards you can limit accesses to funtionalities,
with grants to Indexes you limit accesses to data.
Bye.
Giuseppe

0 Karma

Builder

Thanks... I think what you are saying is in line with what I said in original post.

0 Karma

SplunkTrust
SplunkTrust

Yes, the important thing is to grant access to your indexes to specific role.
Bye.
Giuseppe

0 Karma