Tip

This is the documentation for the 23.02 version. Looking for the documentation of the latest version? Have a look here.

Managing NACM Rules

NACM Rule Lists

NACM rules are contained inside a rule list. A rule list may contain multiple rules, and they are used in the order they are entered. Rule lists are also checked in the order they were created. Consider the order of lists and rules carefully when crafting rule lists.

Create a rule list:

tnsr(config)# nacm rule-list ro-rules

Set the group to which the rule list applies, use group <group-name>:

tnsr(config-nacm-rule-list)# group readonly

See also

For information on defining groups, see NACM Authorization.

NACM Rules

When configuring a rule list (config-nacm-rule-list mode), the rule <name> command defines a new rule:

tnsr(config-nacm-rule-list)# rule permit-all

After entering this command, the CLI will be in config-nacm-rule mode.

From here, a variety of behaviors for the rule can be set, including:

access-operations <name>:

The type of operations matched by this rule. Allowed values include:

Multiple types may be specified in a single command.

*:

Match all operations

Note

This value cannot be combined with other types as the result would be redundant.

create:

Any protocol operation that creates a new data node.

delete:

Any protocol operation that removes a data node.

exec:

Execution access to the specified protocol operation.

read:

Any protocol operation or notification that returns the value of a data node.

update:

Any protocol operation that alters an existing data node.

action <deny|permit>:

The action to take when this rule is matched, either deny to deny access or permit to allow access.

comment <text>:

Arbitrary text describing the purpose of this rule.

Next, the following types can be used to specify the restriction to be enacted by this rule:

module <*>:

The name of the Yang module covered by this rule, for example netgate-nat.

The complete list of modules can be viewed in the CLI by entering module ? from this mode. The REST API documentation also contains a list of modules.

path <path-name>:

XML path to restrict with this rule. This path must include proper namespace prefixes and may also include key restrictions.

For example, to control access to interface state data (e.g. show interface output), use /ngif:interfaces-state/ngif:interface

To control access for a single interface, specify its name in the path: /ngif:interfaces-state/ngif:interface[ngif:name='ipip0']

rpc <rpc-name>:

The name of an RPC call to be restricted by this rule, such as edit-config, get-config, and so on.

Warning

Users with access to modify the configuration (edit-config) should also be granted access to read the same paths (e.g. get-config). If a user only has edit-config access to a path, the user may receive an access-denied message in the CLI for that path when attempting to use a configuration command which makes a modification. This can happen because validation of certain commands requires reading the configuration to determine if the attempted command contains appropriate values.

NACM Rule Examples

As shown in NACM Example, the following set of commands defines a rule list and then creates a rule to permit access to everything in TNSR:

tnsr(config)# nacm rule-list admin-rules
tnsr(config-nacm-rule-list)# group admin
tnsr(config-nacm-rule-list)# rule permit-all
tnsr(config-nacm-rule)# module *
tnsr(config-nacm-rule)# access-operations *
tnsr(config-nacm-rule)# action permit
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# exit

Using the available module and access-operation, rules are possible that limit in more fine-grained ways.

This next example will allow a user in the limited group to see information from commands like show, but not make changes to the configuration:

tnsr(config)# nacm rule-list limited-rules
tnsr(config-nacm-rule-list)# group limited
tnsr(config-nacm-rule-list)# rule read-only
tnsr(config-nacm-rule)# module *
tnsr(config-nacm-rule)# access-operations read exec
tnsr(config-nacm-rule)# action permit
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# exit

Selective restrictions are also possible with rules that limit access to specific modules while allowing access to everything else. In this example, users in the limited group may access any module except for NTP.

tnsr(config)# nacm rule-list limited-rules
tnsr(config-nacm-rule-list)# group limited
tnsr(config-nacm-rule-list)# rule no-ntp
tnsr(config-nacm-rule)# module netgate-ntp
tnsr(config-nacm-rule)# access-operations *
tnsr(config-nacm-rule)# action deny
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# rule permit-all
tnsr(config-nacm-rule)# module *
tnsr(config-nacm-rule)# access-operations *
tnsr(config-nacm-rule)# action permit
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# exit

Restricting by path allows fine-grained control over specific areas of configuration and state data. This example denies access to show interface commands if a user is in the limited group:

tnsr(config)# nacm rule-list limited-rules
tnsr(config-nacm-rule-list)# group limited
tnsr(config-nacm-rule-list)# rule no-interface-state
tnsr(config-nacm-rule)# action deny
tnsr(config-nacm-rule)# path /ngif:interfaces-state/ngif:interface
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# rule permit-all
tnsr(config-nacm-rule)# action permit
tnsr(config-nacm-rule)# exit
tnsr(config-nacm-rule-list)# exit

NACM Rule Processing Order

When consulting defined rule lists, NACM acts in the following manner:

  • If NACM is disabled, it skips all checks, otherwise it proceeds

  • NACM consults group lists to find which groups contain this user

  • NACM checks each rule list in the order they are defined

  • NACM checks the group membership for each of these rule lists

  • NACM compares the group defined on the rule list to the groups for this user, and if there is a match, it checks rules in the list

  • NACM checks the rules in the order they are defined inside the rule list

  • NACM compares the current access operation to the rule and if it matches, the rest of the rule is tested

  • NACM attempts to match the following criteria, if defined on the rule:

    • The module on the rule name must match the requested module or *.

    • The rpc-name matches the RPC call in the request

    • The path matches the XML path to the requested data

  • If the rule is matched, NACM consults the action on the rule and acts as indicated, either permitting or denying access

  • NACM repeats these checks until there are no more rules, and then no more rule lists

  • If no rules matched, NACM consults the default policies for the attempted operation and takes the indicated action