authorization

Pre-Alpha. This page describes behavior that may change.

Ze supports profile-based command authorization. Each user can be assigned an authorization profile that controls which operational (run) and configuration (edit) commands are permitted or denied. Profiles are defined under system { authorization { profile { } } } and matched against the commands a user issues.

A minimal setup

system {
    authorization {
        profile operator {
            run {
                default-action allow;
            }
            edit {
                default-action deny;
            }
        }

        profile admin {
            run {
                default-action allow;
            }
            edit {
                default-action allow;
            }
        }
    }
}

This gives operator full read access but no configuration rights, and gives admin unrestricted access to both.

Configuration reference

Path	Type	Default	Description
system/authorization/profile <name>	list	--	Named authorization profile, keyed by name.
profile/run/default-action	enum	--	Action when no run entry matches: allow or deny.
profile/run/entry <number>	list	--	Ordered authorization entry for operational commands.
profile/run/entry/action	enum	--	allow or deny this match.
profile/run/entry/match	string	--	Command path prefix or regex pattern to match against.
profile/run/entry/regex	boolean	--	When true, the match value is a regular expression.
profile/edit/default-action	enum	--	Action when no edit entry matches: allow or deny.
profile/edit/entry <number>	list	--	Ordered authorization entry for configuration commands.
profile/edit/entry/action	enum	--	allow or deny this match.
profile/edit/entry/match	string	--	Command path prefix or regex pattern to match against.
profile/edit/entry/regex	boolean	--	When true, the match value is a regular expression.

YANG structure

The YANG module ze-authz-conf defines the schema:

container system {
    container authorization {
        list profile {
            key "name";
            leaf name { type string; }

            container run {
                leaf default-action { type enumeration { enum allow; enum deny; } }
                list entry {
                    key "number";
                    leaf number { type uint32; }
                    leaf action { type enumeration { enum allow; enum deny; } }
                    leaf match  { type string; }
                    leaf regex  { type boolean; }
                }
            }

            container edit {
                leaf default-action { type enumeration { enum allow; enum deny; } }
                list entry {
                    key "number";
                    leaf number { type uint32; }
                    leaf action { type enumeration { enum allow; enum deny; } }
                    leaf match  { type string; }
                    leaf regex  { type boolean; }
                }
            }
        }
    }
}

How profiles are assigned to users

Profiles are associated with user accounts in the system user database. User management is covered in system.md. Once a profile name is defined here, it can be referenced from a user entry so that every session for that user inherits the profile's authorization rules.

The run and edit sections

Each profile contains two independent sections:

• run -- governs operational (read-only) commands: show commands, status queries, CLI diagnostics, and anything that does not modify configuration.
• edit -- governs configuration (write) commands: setting values, deleting nodes, committing changes, and rollback operations.

Both sections work identically. They have a default-action and an ordered list of entries. The two sections are evaluated independently: a user can be allowed to run show commands but denied all configuration changes.

Entry matching

Entries are evaluated in order by sequence number (lowest first). The first matching entry wins. If no entry matches, the default-action applies.

Each entry has:

Field	Purpose
action	allow or deny -- what happens when this entry matches.
match	A command path prefix (e.g. bgp peer) or a regex pattern.
regex	When true, match is treated as a regular expression instead of a literal prefix.

Prefix matching is the simple case: if the command the user types starts with the match string, the entry applies. Regex matching (regex true) gives full control, including wildcards and alternation.

Example: read-only operator profile

An operator who can view everything but change nothing, except they are also denied access to security-sensitive show commands:

system {
    authorization {
        profile read-only-operator {
            run {
                default-action allow;

                entry 10 {
                    action deny;
                    match "system authorization";
                }
                entry 20 {
                    action deny;
                    match "^.*password.*$";
                    regex true;
                }
            }
            edit {
                default-action deny;
            }
        }
    }
}

Entry 10 blocks system authorization commands by prefix. Entry 20 uses a regex to deny any command containing password. Everything else under run is allowed. All edit commands are denied.

Example: full admin profile

An admin with no restrictions:

system {
    authorization {
        profile full-admin {
            run {
                default-action allow;
            }
            edit {
                default-action allow;
            }
        }
    }
}

No entries are needed -- the default action covers everything.

Example: BGP-only operator

An operator who can view and modify BGP configuration but nothing else:

system {
    authorization {
        profile bgp-operator {
            run {
                default-action deny;

                entry 10 {
                    action allow;
                    match "bgp";
                }
                entry 20 {
                    action allow;
                    match "show bgp";
                }
            }
            edit {
                default-action deny;

                entry 10 {
                    action allow;
                    match "bgp";
                }
            }
        }
    }
}

See also

• System for user management and SSH configuration.
• Overview for the surrounding config model.
• Editor workflow for how configuration changes are committed.