On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
Introduction Openstack is an open source cloud service implementation Keystone is the security module of Openstack Current authorization system implemented in keystone is single-tenant Multi-tenancy support is defined as the capability of a single software instance to provide its service to several parties simultaneously Our objective is to convert this single tenant system into a multi-tenant one
Current implementations of authorization is based on a 3 tuple implementation namely (Subject, Privilege, Object) This needs to be changed to incorporate multi-tenancy The basic multi-tenant system would have a structure in the form of a 5 tuple namely (Issuer, Subject, Privilege, Interface, Object) This implementation though useful is not enough We try to use a RBAC incorporated implementation This new model which has RBAC changes the 5 tuple to (Issuer, role(Issuer, RoleName), Privilege, Interface, Object)
(IssuerA, role(IssuerB, users), Read, ServiceA.1, root) isinterpreted as IssuerA grants anybody with role(IssuerB,users) Read access to the root folder of the file systemprovided by ServiceA.1.
Keystone Layout Keystone directories were found in the following locations /opt/stack This contained all the necessary python modules to keep keystone running including the policy engine /var/lib This contained the keystone.db file used to initialise the backend /usr/share This contained shell files to automatically crate new users in opentack /etc This contained the keystone.conf file and the default catalog templates file
Policy Trace Once an access is made to any protected resource the authorization entry point is in rules.py enforce() common.policy.enforce() Brain.check() _check() _check_rule() or _check_role() or _check_service() or _check_generic() depending on the match in the rules dictionary. These functions recursively call Brain.check() to help matches nesting of rules appropriately.
Our Implementation To implement the 5 tuple we add the following to the current implementation The Service as a part of both the cred_dict and rules_dict The role is now a 2 tuple mapping between issuer and name of the role, again this is added to both cred_dict and rules_dict New function called _check_service is implemented Access is allowed only if all the elements in the match_list match that of the cred_dict