How to manage authorize.conf and authentication.conf in a SHC?

[Jamie]

Hello.

I am running 8.2.2 on Linux.  I have a SHC with three members.

I have three indexes.  I would like to restrict the searchable index for each role and I would like to understand the best way to distribute that change.

I used the web GUI to create the roles, which the cluster replicated.  However, the GUI does not permit non-internal indexes to be deselected.  Therefore, I have edited authorize.conf on each member.  I am using srchIndexesDisallowed.  An account with role_user_a should only be able to search index_a.   The configuration below works, but how should I manage changes like this given the GUI limitation -- should I continue to edit the file directly (along with authentication.conf) going forward (and not use the GUI)?

$ splunk btool --debug authorize list role_user_a
/opt/splunk/etc/system/local/authorize.conf [role_user_a]
/opt/splunk/etc/system/local/authorize.conf cumulativeRTSrchJobsQuota = 0
/opt/splunk/etc/system/local/authorize.conf cumulativeSrchJobsQuota = 0
/opt/splunk/etc/system/local/authorize.conf importRoles = user
/opt/splunk/etc/system/default/authorize.conf rtSrchJobsQuota = 6
/opt/splunk/etc/system/default/authorize.conf run_collect = enabled
/opt/splunk/etc/system/default/authorize.conf run_mcollect = enabled
/opt/splunk/etc/system/default/authorize.conf schedule_rtsearch = enabled
/opt/splunk/etc/system/default/authorize.conf srchDiskQuota = 100
/opt/splunk/etc/system/default/authorize.conf srchFilterSelecting = true
/opt/splunk/etc/system/local/authorize.conf srchIndexesAllowed = index_a
/opt/splunk/etc/system/local/authorize.conf srchIndexesDefault = index_a
/opt/splunk/etc/system/local/authorize.conf srchIndexesDisallowed = index_b;index_c
/opt/splunk/etc/system/default/authorize.conf srchJobsQuota = 3

Thanks for your help.

[pbrinkman]

thanks @dural_yyz  do you have an example of the actual configuration.  Thanks what I am struggling with at the moment, knowing what the config should look like in authorise.conf

cheers

[dural_yyz]

I can't show how my configuration is exactly so here is a mock up of general rules.

[role_user-clone]
<omitted but all default user capabilities should be here as well>
## Validate upgrades don't change default capabilities, keep in sync post upgrade
srchIndexesAllowed = main; index-1; index-n
srchIndexesDefault = main

[role_custom]
srchIndexesAllowed = index-A; index-B
importRoles = user-clone

Here the custom user will inherit all rights of the user-clone for search Indexes Allow which doesn't include wild cards so is restrictive, but often environments may have index(es) which all users can view.

Post upgrades in our environment we audit all Splunk Default roles against our cloned roles for any capability changes.  We use this more to ensure restricted access to indexes than any other capability control (ex: we don't mess with capabilities for sharing or report building).

Just make sure that your custom roles do not import default roles or they will inherit default search indexes.

[isoutamo]

Hi

my 2 cents for this.

You definitely should manage all configurations (which you can) by Deployer on SHC. Otherwise you will have huge mesh quite soon 😞

Don't mix access and capabilities on one role!!! Those should be always in separate roles. Otherwise you will get really hard times to debug why something works or not on users.

Don't do inheritance chains like 

role1 -> role2 -> role3 -> role4

It's much easies debug/know what you have when when you do only one level inheritance

role1 -> role4
role2 -> role4
role3 -> role4

 Try to create your own base roles instead of use splunk's user/power/admin where inherit to another. Then you always know what capabilities those have instead of guessing what has changes when Splunk versions has updated.

r. Ismo

[isoutamo]

One more. I haven't ever understand why there should be 

srchIndexesDefault

My advice is don't use it! With this your users never learn to define index=abc and then you need to debug why one can see data and other cannot! Much better to force them to use indexes on search.

Another is

srchFilter

 that will generate much more issues than solve those if you have environment with several roles etc.

[dural_yyz]

You already have your answer that work for you which is great.

In our environment we cloned the default user and removed the allowed=* from the clone.  We build all roles to inherit the cloned user account.  That way you have all the same capabilities but don't inherit the allowed=* for indexes.

Food for thought.

[pbrinkman]

hi @dural_yyz  many thanks for the response.

Do you have an example of what the config likes. I know what I am trying to achieve but struggling with what the actual config should look like

[pbrinkman]

Agree with @richgalloway  the gui doesnt allow the flexibility to manage users / roles.  Although it would be nice to see some clear documentation as to how to set this up from a deployer server correctly.  Does anyone have any configuration examples ?

[Jamie]

@richgalloway,

Thanks for the quick response.  I had considered that, but given that both files are included in the SHC replication I thought that might lead to problems.  Do you manage the files that way and does that mean further GUI edits of both files need to be avoided, do you know?  Thanks again.

[richgalloway]

The fact that the GUI doesn't let you do all you need to do should be enough to steer you toward another method.  IMO, clusters should be managed as clusters, with the deployer as the Source of Truth for what the configuration should be.  Configuration changes should be made at the deployer and then deployed to SHC members.

[richgalloway · Accepted solution]

Move the settings from etc/system/local/ to an app then deploy the app from the SHC deployer.