NACM rule to restrict a user from deleting any service instance

[equinix]

Hi,

Following is the NACM rule we have defined to restrict users from deleting LAG service instances.

admin@ncs% show nacm rule-list api rule service-l2lag-instance-delete

module-name       tailf-services;

path              /services/l2lag:l2lag[lag-id='$ID'];

access-operations delete;

action            deny;

Service Xpath

/services/l2lag:l2lag[lag-id='101'] - If we define this as a path value, it is working as expected. But we would like to extend the same behavior for all LAG instances.

Could you please look into the XPATH we have defined in service-l2lag-instance-delete NACM rule and let us know if need to update anything to achieve the behavior we expect.

Best Regards

Sandeep.T

[yfherzog]

Hi,

I'm not sure if I understand exactly what is the gap between what you did and what you want to achieve.

In any case, I think the path on your rule can simply be: 'path /services/l2lag:l2lag'.

Yftach

[equinix]

Hello Yftach,

Thank you for the response. Yes, we can use XPath " /services/l2lag:l2lag" for applying a rule on all instances of a LAG service.

To be more clear, But we would like to permit/deny a user to access only one instance per request.

Following are the rules we are trying to define using NACM

1. Restrict a User from deleting all services – Done
2. Restrict a User from deleting all instances of a specific service - Done
3. Permit a User to delete a service instance of a specific service – Not working - For example, Let's say we have 100 LAG instances created and we like to permit a user to delete only one instance at a time. What XPath to use for defining a rule?

Following are the NACM rules, we have defined to achieve the same. Could you please look into it and let us know if we need to update anything to achieve the behavior we are looking for

------- Restrict a User{api} from deleting all services with one request -----

set nacm rule-list api rule service-access module-name tailf-services

set nacm rule-list api rule service-access path /services

set nacm rule-list api rule service-access access-operations create,read,update

set nacm rule-list api rule service-access action permit

-------------------

------- Restrict a User{api} from deleting all instances of a specific service with one request ------

set nacm rule-list api rule service-l2lag-delete module-name tailf-services

set nacm rule-list api rule service-l2lag-delete path /services/l2lag

set nacm rule-list api rule service-l2lag-delete access-operations create,read,update

set nacm rule-list api rule service-l2lag-delete action permit

---------

------- Permit a User to delete one service instance at a time per request of a specific service---

set nacm rule-list api rule service-l2lag-instance-delete module-name tailf-services

set nacm rule-list api rule service-l2lag-instance-delete path /services/l2lag:l2lag[lag-id='$ID'] – Please advise if this is a valid XPATH to define.

set nacm rule-list api rule service-l2lag-instance-delete access-operations delete

set nacm rule-list api rule service-l2lag-instance-delete action permit

---

LAG service XPATH : /services/l2lag:l2lag[lag-id='101'] - If we define this as a path value for a rule service-l2lag-instance-delete, it is working as expected. But we would like to extend the same behavior for all LAG instances.

Best Regards

Sandeep.T

[yfherzog]

Hi,

Looking at the NSO admin guide, those are the option for defining the path argument:

path:

A restricted XPath expression leading down into the populated XML tree. A rule with a path specified matches if it is equal to or shorter than the checked path. Several types of paths are allowed.

1. Tagpaths that are not containing any keys. For example /ncs/live-device/live-status.

2. Instantiated key: as in /devices/device[name="x1"]/config/interface matches the interface configuration for managed device "x1" It's possible to have partially instantiated paths only containing some keys instantiated - i.e combinations of tagpaths and keypaths. Assuming a deeper tree, the path /devices/device/config/interface[name="eth0"] matches the "eth0" interface configuration on all managed devices.

3. Wild card at end as in: /services/web-site/* does not match the web site service instances, but rather all children of the web site service instances. Thus the path in a rule is matched against the path in the attempted data access. If the  attempted access has a path that is equal to or longer than the rule path - we have a match.

Are you trying to prevent the user from deleting all instances at the same time, but allowing the deletion of any of those instances if this is done by providing the specific instance name on its own?

Something like allowing this:

no services service-a instance-1

no services service-a instance-2

but denying this:

no services service-a

If so, for deletion through CLI, you can achieve that through the use of cmdrules.

Yftach

[equinix]

Hi Yftach,

Yes, we would like to prevent the user from deleting all instances of a service per request and allowing the user to delete one service instance at a time.

As we expose these services to northbound via REST. We would like to apply these rules to REST URI.

As mentioned above, "/services/l2lag:l2lag[lag-id='101'] path is working if applied to a rule. But we would like to have a way to pass a variable instead of "101" to extend this behavior to all service instances.

Best Regards

Sandeep.T

[yfherzog]

Hi,

Still not sure I'm following the last part about passing a variable, but in any case, if the functionality you're after is possible, I can't say I know how to accomplish that, but might be that someone else here would have some insights.

Sorry.

Yftach

[Jan Lindblad]

There is no way to express this with a NACM rule. With NACM, the operator is either allowed to delete any given object, or he's not. NACM rules do not work on the level of which commands you use to perform a particular operation.

If you want to implement guard rails like this, consider implementing a custom validation function that may issue a warning (to CLI and Web users, not to NETCONF/RESTCONF) if the configuration is changed in a 'dramatic' or 'dangerous' way.

You can also implement a command authorization function to look at each command and approve it, but I think the validation function option would be better.

[lmanor · Accepted solution]

Here is another idea to prevent undesired erroneous deletion (credit to <hitakaha@cisco.com>):

Add a flag into the service model and use preModification() to check it.

First, add a new Boolean leaf to service model, say to_delete=[true|false] .

Inside java/python code, use preModification() and check the leaf only  on DELETE operation.

If the flag is to_delete=false, throw an error.

So, when the operator wants to delete an instance, they need two steps:

First, set the to_delete flag as true for the service instance to be deleted.

Second, issue the delete with -X DELETE for the service instance.

2 REST calls, but safer deletion if concerned that the northbound can shoot itself in the foot.

[equinix]

Hi larry,

Thank you for the suggestion.

With this approach, we can restrict a user from deleting all instances of a specific service.

But, what if a user triggers a DELETE  operation on the following rest URI /api/running/services. With this trigger, he will still be able to erase all the services.

Is there any way to restrict a user from doing this.

Best Regards

Sandeep.T

[lmanor]

Sandeep,

Actually, if any of your services in the /services branch failed the delete (as would happen for all service instances if the pre-mod check approach was implemented on any of your services) then the attempt to 'delete /api/running/services' would fail and therefore all services will not be deleted.

-Larry

[equinix]

Great.. Thank you.

Will try this approach then.

Best Regards

Sandeep.T

[NigelWest]

Hi Sandeep,

I have a similar scenario, and wanted to try and avoid command rules because I can see them getting very messy.  Did you manage to find a workable solution, based on the suggestions in this thread?

Regards,

Nigel.

[smadappa]

Hi,

I believe you can do this by.

for operation 'delete':

deny /services/l2lag:l2lag

permit /services/l2lag:l2lag/*

Regards,

Shameer