How does role composition work?

[juniormint]

http://docs.splunk.com/Documentation/Splunk/6.0/Security/Aboutusersandroles#How_users_inherit_search...

I read the blurb above, but still find myself with questions.

Not using inheritance, but rather composition.

What would I expect to happen if:

Role A : gives search on index XYZ, with search filter "source=XYZ_App1"
Role B : gives search on index XYZ, with search filter "source=XYZ_App2"
Role C : gives search on index XYZ, with no search filter
Role D : gives search on index 123, with search filter "source=123_test"
Role E : gives search on index XYZ, with search filter source=XYZ_App1 ERROR
Role F : gives search on index 123, with search filter source=123_test INFO

User1 is assigned Role A and Role B
User2 is assigned Role A and Role C
User3 is assigned Role A and Role D
User4 is assigned Role E and Role F

What will the effective search filter be for these users?

Any advice in the way of gotchas around composing roles?

[lguinn2]

My suggestion: try not to use search filters for composing roles.

Use indexes to segregate data by visibility as much as possible. For example,

The networking team should see only firewall data

The ops team should see only server data

The security team can see all data

Then create 2 indexes: network and server. Give the networking role access to its index, and ditto for the ops role. Give the security role access to both indexes.

Why is this better? I can think of a few reasons off-hand

1 - It is a lot easier to understand and manage than a bunch of filters OR'ed together

2 - Searches will run faster because they are not applying extra criteria or examining unnecessary data

3 - Different levels of data security (such as encryption) can be applied to indexes

Is this always the best answer? No. Having 30 little indexes doesn't work either. But I try to avoid search filters as much as practical.

Important: Roles inherit BOTH capabilities and index visibility. Example: Given the roles above, I want to create a new role for the web team. They will have the same capabilities as the security role, so I create the web role as inheriting from the security role -> I just gave the web role access to the network and server indexes! So be aware of this, no matter how you chose to set up your roles.

[juniormint]

Upvoting because @lguinn's comments seem very relevant...and probably accurate

[juniormint]

@lguinn: Am I missing functionality or approaches that handle large numbers of sources with different access groups better?

[lguinn2]

Yikes - I would not suggest 500 indexes! This would surely make searches much longer and negate any performance benefits I mentioned. And it would of course make things at least as complicated to manage.

I think you have a great counter example to my suggestions!

[juniormint]

@lguinn: It's a balance though. My use case is that I will have many sources (>500), each with potentially different and overlapping sets of users with search access.

The daily data rate for each source is between 0 and about 10000 events.

Generally, events are only relevant for a day or two...so historical searches are the exception.

Should I really set up 500 indexes? Or would one index with all of the sources be better?

[juniormint · Accepted solution]

User1 filter (source=XYZ_App1 OR source=XYZ_App2)
User2 filter (source=* OR source=XYZ_App1)
User3 filter (source=XYZ_App1 OR source=123_test)
User4 filter ((source=XYZ_App1 AND ERROR) OR (source=123_test AND INFO))

Applied to whatever combined set of indexed the roles can search.

[juniormint]

I think this is literally the answer to my primary question.