public
public copied to clipboard
openconfig
Update AAA model to make user role a mandatory attribute
* (M) release/models/system/system-aaa.yang
* (M) release/models/system/system-aaa-radius.yang
* (M) release/models/system/system-aaa-tacacs.yang
- Update role to be mandatory attribute of user configuration
This is to address the undefined behavior when a system user is created but no role is specified. Implementations vary in their behavior here - proposal is to make role a mandatory attribute.
Original proposal was to define new system defined user roles and specify one as a default - conversation resulted in going the direction of simply making the role mandatory: https://github.com/openconfig/public/pull/682
Hi aredmon8551 - can you clarify what this 'role' leaf maps to in some common router implementations ? (ideally with a specific config path/command ?).
For example: Cisco IOS-XR and Nokia SR OS both have the concept of a 'group' that is a user can be associated with, but those can have user defined names (i.e. not so much a built-in 'role' that would be defined as an identity).
Hi aredmon8551 - can you clarify what this 'role' leaf maps to in some common router implementations ? (ideally with a specific config path/command ?).
For example: Cisco IOS-XR and Nokia SR OS both have the concept of a 'group' that is a user can be associated with, but those can have user defined names (i.e. not so much a built-in 'role' that would be defined as an identity).
##Junos EVO
me@evo_router# set system login user test class ?
Possible completions:
<class> Login class
operator permissions [ clear network reset trace view ]
read-only permissions [ view ]
readonly
super-user permissions [ all ]
unauthorized permissions [ none ]
wheel
##Arista EOS
eos_router(config)#username test role ?
WORD Role name
###Cisco NX-OS
nx_os_switch(config)# username test role ?
dev-ops User role
network-admin System configured role
network-operator System configured role
priv-0 Privilege role
priv-1 Privilege role
priv-10 Privilege role
priv-11 Privilege role
priv-12 Privilege role
priv-13 Privilege role
priv-14 Privilege role
priv-15 Privilege role
priv-2 Privilege role
priv-3 Privilege role
priv-4 Privilege role
priv-5 Privilege role
priv-6 Privilege role
priv-7 Privilege role
priv-8 Privilege role
priv-9 Privilege role
vdc-admin System configured role
vdc-operator System configured role
@jsterne reading through the docs for IOS-XR and SR-OS, group looks to be the equivalent to role - note that the leaf still supports a string. SR-Linux looks to use 'roles' if I'm reading those docs right.
The IOS-XR and SR OS user groups are probably often used as a "role", but those would be either user-created groups (where command auth permissions are defined) or maybe in some cases some built in groups as well. But it feels like a somewhat different concept than a hard-coded set of identityref-based roles like some of the older priv lvl concepts. I suppose the fact that an arbitrary string is accepted can help for mapping to those 2 OSes. But I don't think the OpenConfig model actually supports the creation/configuration of those groups right ? So if the role is mandatory it may be tricky on systems where a user created role (group) is needed (i.e. really a leafref).
Is there any interaction to also consider here with the relatively new gNMI command authorization work ? That is proto-based (not YANG modelled) and has users & groups (not really a concept of a mandatory 'role').
The IOS-XR and SR OS user groups are probably often used as a "role", but those would be either user-created groups (where command auth permissions are defined) or maybe in some cases some built in groups as well. But it feels like a somewhat different concept than a hard-coded set of identityref-based roles like some of the older priv lvl concepts. I suppose the fact that an arbitrary string is accepted can help for mapping to those 2 OSes. But I don't think the OpenConfig model actually supports the creation/configuration of those groups right ? So if the role is mandatory it may be tricky on systems where a user created role (group) is needed (i.e. really a leafref).
Is there any interaction to also consider here with the relatively new gNMI command authorization work ? That is proto-based (not YANG modelled) and has users & groups (not really a concept of a mandatory 'role').
Right, there's the option to use a hard-coded identityref or a string. This is an incremental improvement over the existing behavior of "just create a user and leave it up to the implementation to decide what default permissions are appropriate".
For gNSI, I'm only aware of what's been published to date (https://github.com/openconfig/gnsi/tree/main/authz). Believe the approach only covers gRPC authorization.
//cc @marcushines too.
There's some discussion of the way that SSH authentication could work in gNSI (https://github.com/openconfig/gnsi/tree/main/ssh) that is being discussed. I think that (from my perspective) it's probably difficult for us to say (in a way that works across operators) that one must move to gNSI to get some specific functionality -- since I expect that there are a number of operators that won't make that transition (at least not yet).
The interaction between gNSI-configured policies and gNMI/OpenConfig-configured ones is definitely something to be considered -- my (potentially naive) view was that this would work akin to authentication orders that we have today, i.e., use X first, and if not available fallback to Y.
w.r.t whether we can make this mandatory, @jsterne -- today, does SROS have well-defined roles? If so, then this wouldn't necessarily prevent having the leaf as mandatory, but I agree that if we want more complex 'role' definitions than these built in ones, creation of that group in the context of the OpenConfig models will be required.
I'm not familiar with that gNSI authorization but the work I was thinking of was this: https://github.com/openconfig/public/pull/524
Making 'role' mandatory when the OpenConfig model doesn't have a way to create roles may not be a good step to take. And if we added groups/roles to the model, I'm a bit doubtful we'd want to call them 'role' (might be better to call it 'group' or maybe 'class' ?). But overall it is still a little unclear how authorization for access to certain commands or areas of config is intended to work between this 'role' leaf vs that PR#254 I linked above.
w.r.t whether we can make this mandatory, @jsterne -- today, does SROS have well-defined roles? If so, then this wouldn't necessarily prevent having the leaf as mandatory, but I agree that if we want more complex 'role' definitions than these built in ones, creation of that group in the context of the OpenConfig models will be required.
SR OS doesn't really have any hard coded roles per-se. The config model has users and groups. The groups define the access permissions (e.g. read-write to path x/y/z, no access to path a/b/c, etc) and users are configurably associated with groups. I'm pretty sure JUNOS and IOS-XR have similar mechanisms. We do have a few built-in users and groups available if the router boots without a config (the operator can use those or delete them, e.g. the 'admin' user account). But I wouldn't call those 'roles'. These groups are fairly flexible/arbitrary.
I guess the argument for allowing config before there is a group specification in OC is that there are implicit roles - e.g., the privilege levels, or well-known role/groups - then a user that is configured through this mechanism is going to be implicitly assigned to one of them anyway.
If we don't make this mandatory - then what would SROS do with such a user, does it map it into one of the known groups, or error? (If it errors, it effectively already has made it mandatory.)
We do map that leaf to our two built in groups (called 'profiles' in SR OS): admin and default. We don't error if there isn't a role (but from a security POV we then give that user basically no access).
The concept of having a user associated with some sort of configurable 'role' (I prefer the term 'group' but that's minor) seems good. But making this concept mandatory without having the roles/groups configurable was worrying me:
- it seems like a fairly common way to configure AAA on IOS-XR, junos, SR OS, SRL, etc (i.e. to create an operator-specified set of roles/profiles with access to certain commands/branches)
- confusion about how it would interact with PR#254
Hi all - I didn't realize there was already discussion around this topic in PR#682 (e.g. examples were already provided there - sorry I missed that). I'll take a look at the comments there as well.
After looking through PR#682 and thinking about this more, I think it is probably OK to make this mandatory. There is still the question of how role (and permissions associated with those roles) interact with https://github.com/openconfig/public/pull/524 but perhaps that can be a separate discussion.
Reviewed in OC operators and OC community meeting without objections. Since we are over 14 days without further comments, I will merge this now.
