1. By-
Anush V
Meghana Prashanth
Pramod Ramesh
Ashwin Sethi
2. 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
3. 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)
4. (IssuerA, role(IssuerB, users), Read, ServiceA.1, root) is
interpreted as IssuerA grants anybody with role(IssuerB,
users) Read access to the root folder of the file system
provided by ServiceA.1.
5. 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
6. 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.
7. 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