Paul, I2NSF team,
Certainly. Find my proposed sketch for the module structure attached. I think it is important for the adoption of this module that it is reasonably easy to implement it on top of existing NETCONF/RESTCONF/YANG servers. They all implement the NACM management access control mechanism today, so the ietf-i2nsf-cfi-policy module should build on that. It's therefore important to leverage the existing NACM mechanisms and concepts for groups, users, permissions. It would be technically possible to set up all the management access control rules needed to implement the I2NSF ideas by only creating rules in NACM. The NACM rules are massively more complex than the simple owner leaf proposed in your YANG module, however. From a usability perspective I think it makes good sense to keep the abstraction in ietf-i2nsf-cfi-policy and let the module implementor make sure this high level authorization view is translated into NACM specifics. In order to make this feasible, I changed the owner string leaf into a leafref pointer to NACM groups, and removed the module's separate identities for permissions. Let's adopt the NACM counterparts instead. The structure of the rules was very flat, i.e. the domains, tenants, policies and rules were mostly side by side, not reflecting their logical hierarchy in the YANG. This would make the number of NACM rules to control access to each individual item very high. By arranging them in a tree structure, I believe the number of NACM rules can be kept to a minimum. NACM rules may have a high impact on server performance, so it's important to not have excessive amounts of them. I created a hierarchy with domains on top, each domain containing zero or more tenants, each with zero or more policies that in turn consist of zero or more rules. At each level it is possible to list owners in the form of NACM groups. The module implementor would then have to translate these owner references to actual NACM rules. Here is an example sketch configuration and the resulting NACM rules (in CLI style syntax for readability): i2nsf-cfi domains domain example.com owners [ example.com--eng-it ] tenants tenant dev policies policy team-black owners [ example.com--dev ] rules rule 2 ! rules rule allow-malware-sites owners [ example.com--dev ] This is supposed to mean that members of the example.com--eng-it group have full ownership of everything in the example.com domain. Within this domain, there is a tenant called dev, with a policy called team-black. That policy is owned by example.com--dev. This means this policy may be updated by members in example.com--dev and example.com--eng-it. Within the policy there are two rules ("2" and "allow-malware-sites"). The "allow-malware-sites" rule has the example.com--dev group listed as owner; this is superfluous. In this example, the rules are otherwise empty. In order for existing NC/RC/YANG servers to enforce the above, the ietf-i2nsf-cfi-policy module implementation would need to translate the intent above to NACM rules like the ones below. In this example, the implementation created a rule to allow members of the dev and eng-it groups within the example.com org to see the example.com domain and everything within it. Next there is a rule to allow members of the example.com dev group to update the policy named team-black within the dev tenant. Finally, there is a rule to allow the eng-it group members to update anything within the example.com domain. The default nacm policy per statement in the YANG is to deny anyone else to see anything within the i2nsf domain. nacm rule-list example.com group [ example.com--dev example.com--eng-it ] rule read-all path /i2nsf-cfi/domains/domain[name='example.com'] access-operations read action permit ! ! nacm rule-list example.com--dev group [ example.com--dev ] rule 1 path /i2nsf-cfi/domains/domain[name='example.com']/tenants/tenant[name='dev']/policies/policy[name='team-black'] action permit ! ! nacm rule-list example.com--eng-it group [ example.com--eng-it ] rule 1 path /i2nsf-cfi/domains/domain[name='example.com'] action permit ! ! NACM also contains a mapping from user names to groups. Is this in line with your expectations? Do we need additional infrastructure to control this mapping? nacm groups group example.com--dev user-name [ jan vasilij ] ! nacm groups group example.com--eng-it user-name [ chris victor ] ! nacm groups group example.com--finance user-name [ clara sakura ] ! What do you think about this approach to the management access control? I'm not sure I got the relations between domains, tenants, policies and rules as you want them. Are all these levels needed? Do you believe this is this is a workable approach to your vision? Please let me know if you would like me to take any further steps with this sketch. I should mention that I also have plenty of other comments on your updated module, but I want to get the access control approach resolved before looking at anything else.
Then it is all the more important that the solution can be implemented on top of the existing servers out there without modifying them. Best Regards, /jan |
Attachment:
ietf-i2nsf-cfi-policy-sketch.yang
Description: Binary data
