NSO NACM rules - config assistance

[rabaldeo]

I need to give the ncsoper group access to be able to add/remove static routes or BGP prefixes in our service models, but they should not have access to any other leaf in the service model or be able to do device configs. How does once configure this as a nacm rule?

The path is:

jacom@ncs(config)# services l3vpn L3VPN_1_1 is-vrf-cpe-inband-mgmt endpoint is-vrf-cpe-mgmt_PKL-FW-Interconnect-1 pe-ce-rp
Possible completions:
routing-protocol routing-protocol choice: eBGP / static
static-parameters
<cr>

They should thus be allowed to configure anything under "pe-ce-rp" but not do anything else.

[jvikman]

Something like this:

 <rule-list>
<name>ncsoper</name>
<group>ncsoper</group>

<rule>
  <name>permit_pe-ce-rp</name>
  <module-name>pypkg</module-name>
  <path xmlns:pypkg="http://example.com/pypkg">/services/pypkg:l3vpn/is-vrf-cpe/endpoint/pe-ce-rp</path>
  <access-operations>*</access-operations>
  <log-if-permit xmlns="http://tail-f.com/yang/acm"/>
 <action>permit</action>
</rule>

 Your <module> and <path> is probably something else.

Used together with restrictive defaults it would be hard for the ncsoper group to do much else I think.

<config xmlns="http://tail-f.com/ns/config/1.0">
 <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
  <enable-nacm>true</enable-nacm>
  <read-default>deny</read-default>
  <write-default>deny</write-default>
  <exec-default>deny</exec-default>
  

This would make it hard to use though, perhaps open up for NETCONF edit-config:

<rule>
 <name>permit_rpc_edit-config</name>
 <module-name>ietf-netconf</module-name>
 <rpc-name>edit-config</rpc-name>
 <access-operations>exec</access-operations>
 <action>permit</action>
 <comment>
  The 'ncsoper' group needs edit-config in order to use the data path rule 'permit_pe-ce-rp'.
 </comment>
</rule>

Hope it helps!

[rabaldeo]

How would one modify the path to make it applicable to any service-type and service name ? Are wildcards accepted? I suppose the rule can be repeated for all the service-types as those are known, but new services with unknown service names are added constantly. e.g for the service below:
aaaa@ncs# show running-config services l3vpn L3VPN_2_1 issa-8936_uat402 | display xpath
/services/l3vpn:l3vpn[service-type='L3VPN_2_1'][name='issa-8936_uat402']/l3vpn-instance-global/vrf/vrf-definition uat402
<config removed for brevity>
/services/l3vpn:l3vpn[service-type='L3VPN_2_1'][name='issa-8936_uat402']/endpoint[id='issa-issal3vpn-169829']/pe-ce-rp/routing-protocol/static/af-type[af-type='ipv4']
/services/l3vpn:l3vpn[service-type='L3VPN_2_1'][name='issa-8936_uat402']/endpoint[id='issa-issal3vpn-169829']/pe-ce-rp/static-parameters/af-type[af-type='ipv4']/static-rp-group/destination-prefix[destination-prefix='10.10.30.0/24'] <-- need ncs-oper user to be able to add destination prefixes but not change anything else

[jvikman]

Hi Randy,

(We discussed this in another medium, but I'll reply here for completeness).

The paths in the rules are node-instance-identifiers, defined in the RFC 8341. Basically the same as instance-identifiers from YANG, but the important part is this section:

If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key.

There's an in Section A4 of RFC 8341 which illustrates this. We have an admin that can do anything to any device:

<rule-list>
    <name>admin-acl</name>
    <group>admin</group>
    <rule>
      <name>permit-interface</name>
      <path xmlns:acme="http://example.com/ns/itf">
       /acme:interfaces/acme:interface
      </path>
      <access-operations>*</access-operations>
      <action>permit</action>
      <comment>
        Allow the ’admin’ group full access to all acme interfaces.
      </comment>
    </rule>
  </rule-list>

And a group named `guest` that can only operate on a devices named `dummy`:

<rule-list>
    <name>guest-limited-acl</name>
    <group>guest</group>
    <group>limited</group>
    <rule>
      <name>permit-dummy-interface</name>
      <path xmlns:acme="http://example.com/ns/itf">
        /acme:interfaces/acme:interface[acme:name=’dummy’]
      </path>
      <access-operations>read update</access-operations>
      <action>permit</action>
      <comment>
        Allow the ’limited’ and ’guest’ groups read
        and update access to the dummy interface.
      </comment>
    </rule>
  </rule-list>