I have 2 roles A and B - they both inherit only from "user" role.
If they create a dashboard in search they cannot edit the permissions to share the dashboard to "App" so the other role or users in the same role can see their dashboard. By default it is built and remains "private".
If I add all capabilities under "power" role (that aren't in "user") to roles A and B they still cannot edit permissions on their own dashboard to share to "app" context so the dashboard an be shared in search app.
If I add "power" to inheritance of roles A and B roles then they can edit the permissions.
What am I missing?
I did find out that the GUI and rest show different things:
REST:
| rest /servicesNS/-/-/configs/conf-authorize splunk_server="local"
| search title IN (role_power role_atest)
| transpose
Now the questions are which one is correct and why are they different?
Hi
When you want to give permission make KOs shared inside app you must give write access to this app for role which you are using. This has done by meta.local or giving write permission inside manage apps GUI panel.
or in local.meta inside this app
[]
access = read : [ * ], write : [ admin, A, B ]
r. Ismo
Thank you for the reply but that is not the issue. The issue is that unless I make a new role inherit "power" it cannot edit the KO. It is not even an option.
My new role inherits user and I then added all of the missing capabilities that are in the Power role but it still will not let my new role have the option to edit permissions.
There must be some capabilities that are not exposed in RBAC and I am trying to figure out what these are.
I know some may say just inherit Power and be done.
My issue is that if Splunk is not exposing all capabilities in the GUI(edit KO permissions) than what else may I be adding to a role by inheriting Power that I am unaware of?
Thank you for the thought. I actually copied that exact settings from default/authorize.conf for the power role and put it in my role in local/authorize.conf.
I then compared the 2 roles with the following:
| rest /services/authorization/roles
| search title IN (power atest)
| transpose
Using all three of these methods of validation the only difference between the roles is the name. Other than that they are exactly the same.
There appears to be something built into the power role that is not exposed under the capabilities settings.
If I copy over all of the same settings(capabilities) to my new role I cannot edit KO permissions. If I inherit the power role in my new role I can.
FYI: As there can be some inheritances between roles etc. I have noticed that those couple of rest queries without recursion are not enough to get all detail information out of those. In my case I have roles which seems to be exactly same with those rest + btool + diff, but after I play some time with that above app I found some differences which are reason for weird behaviour.
I should be very specific and state that it is not an option to edit the permissions on the KO, not that I can't edit the KO itself.
Also, this is a KO (dashboard) created by myself in the role so I own it but still cannot edit permissions unless I inherit Power in the new role I created.