Hi Jan, I will review your suggestion below and tell you our opinion later.
Thanks a lot. Best Regards, Paul On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad <[email protected]> wrote: > Paul, I2NSF team, > > Thanks for your volunteering to improve our Consumer-Facing Interface YANG > Module. > Could you propose a way to redesign ietf-i2nsf-cfi-policy.yang to befit > NACM? > > > 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. > > I am not aware of any particular party interested to implement our data > model. > > > 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 > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
