Hi all, Today on the Neutron-policy IRC, we ran into some issues that we wanted all your feedback on (and as I was writing this note several more occurred to me). It's the problem of conflict resolution: different policies making different decisions about what to do. We have a conflict resolution scheme for when conflicts arise within a single policy, but we have yet to solve the problem of conflicts arising because different policies make different decisions. The important thing to know is that each policy is attached to a tenant (and a single tenant can have multiple policies).
1) We need conflict resolution for the following scenarios. Suggestions? - Two policies for a single tenant have a conflict. - Two policies for different tenants with different Keystone roles have a conflict. For example, we expect that admin policies should supersede non-admin policies (i.e. that if the admin policy makes a decision to either allow or drop a packet, then the non-admin's policy is ignored; otherwise, the non-admin's policy makes the final decision). Are there other roles we need to think about? - Two policies for different tenants with the same Keystone roles have a conflict. For example, if there are two admins whose policies conflict, which one wins? 2) Do we perform conflict resolution at the time policies are created (i.e. at the API level) or do we resolve conflicts more dynamically at run-time? To me, API-level conflict resolution doesn't seem like a good option. Suppose a non-admin writes a perfectly reasonable policy. Then a month later an admin writes a policy that conflicts with the non-admin policy. There's no way to reject the non-admin's policy at this point (and we can't reject the admin's policy). It seems the best we can do is inform the non-admin (via email?) that her policy has been overruled. But if we do that, it may be possible for a tenant to learn what the admin's policy is--whether that is a security problem or not I don't know. 3) What do we do when roles change, e.g. a non-admin user gets promoted to an admin user or vice versa? And how do we find out about role changes if the users do not log in after their policies have been created? That is, role-changes seem to affect the overall policy that is enforced at any point in time and thus role-changes ought to be factored into policy enforcement. Role-changes make me even more dubious that API-level conflict resolution is a good choice. Hopefully that's a reasonable summary. Others will chime in where not. Thoughts? Thanks, Tim _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
