r80.40 - Permission to edit just one group

[Luis_Miguel_Mig]

Hi,
I would like to create a template that would allow just edition of an specific group and installation of those changes.

I have been able to limit access to create common objects, edit a specific inline layer and  permit installation.
However I have a case where I  would like to have tighter control. I would like certain users to be able to add and remove host in a specific group that is installed in a specific rule in a inline layer  and make sure that these users can't delete objects installed in other policies.

Could I do it from the SmartConsole or should I look at the API?

Thanks.
Luis.

[Luis_Miguel_Mig]

I have just noticed that if the object is configured in a policy, it can't be deleted. So that is pretty much what I need.
It would be cool anyway, that I could filter and only show specific objects to that admin profile.

[PhoneBoy]

The permission profiles aren't quite that granular.
Sounds like API is a better approach here.

[Luis_Miguel_Mig]

I have created a basic script in the manager and I call it with a TACP-15 tacacs user from my windows desktop. It works.
Now, I would like to use an user  in TACP-1 with as little permission as possible to run the same script. Any idea?
The number of features at the tacacs configuration at the cli is huge. It is difficult to find out what exactly I need.

I have tried to do the same from the script repository in SmartConsole but you need a superuser there.

I guess that I may need to go down the route of using ansible of something like that to control access to these scripts.

The user case is to allow a team to add ips to an existent group and nothing else.

Tacacs config

add rba role TACP-15 domain-type System all-features

Call from my windows desktop

mgmt_cli.exe run-script -m manager1 script-name "show group" script "/home/_nonlocl/add_host.sh $1" args "1.1.1.1" targets manager1

Script

/usr/local/bin/add_host.sh
file=/usr/local/bin/sid.txt
mgmt_cli -r true login > $file
mgmt_cli -r true -s $file set session new-name $1 description $1
mgmt_cli -r true -s $file add host name $1 ip-address $1
mgmt_cli -r true -s $file set group name Internet members.add $1
mgmt_cli -r true -s $file publish
mgmt_cli -r true -s $file install-policy policy-package test1 targets cluster1
mgmt_cli -r true -s $file logout

[Luis_Miguel_Mig]

I have just realized that my user case it has to do a lot with the Layer Control Access funcionality.
You can configure permission profiles to limit access to specific layers. I think the idea behind is very close to my user case. You can create rules and add existent objects to the rules in the layer your have access. The problem here is that you can't create new objects and you can't modify the existent objects in the layer. I think that it would make sense if the objects in the layer inheritated the permission from the layer.

You can add your user permission to write common objects but then the user can modify any object.

Another thing I don't like about the Layers control Access is that users with access to the child layer, can see the rules of the parent layer. They can't modify the parent layer  but they can see it.

[PhoneBoy]

There are no object-level permissions, you either have access to edit objects or not.
Likewise, if you have access to write to a specific layer, you'll still have read access to related layers.