On 02/05/14 at 03:30am, Vishvananda Ishaya wrote:
On Feb 5, 2014, at 2:38 AM, Florent Flament <florent.flament-...@cloudwatt.com>
wrote:
Hi Vish,
You're approach looks very interesting. I especially like the idea of 'walking
the tree of parent projects, to construct the set of roles'.
Here are some issues that came to my mind:
Regarding policy rules enforcement:
Considering the following projects:
* orga
* orga.projecta
* orga.projectb
Let's assume that Joe has the following roles:
* `Member` of `orga`
* `admin` of `orga.projectb`
Now Joe wishes to launch a VM on `orga.projecta` and grant a role to some user
on `orga.projectb` (which rights he has). He would like to be able to do all of
this with the same token (scoped on project `orga`?).
For this scenario to be working, we would need to be able to store multiple
roles (a tree of roles?) in the token, so that services would know which role
is granted to the user on which project.
In a first time, I guess we could stay with the roles scoped to a unique
project. Joe would be able to do what he wants, by getting a first token on
`orga` or `orga.projecta` with a `Member` role, then a second token on
`orga.projectb` with the `admin` role.
This is a good point, having different roles on different levels of the hierarchy does
lead to having to reauthenticate for certain actions. Keystone could pass the scope
along with each role instead of a single global scope. The policy check in this could
be modifed to do matching on role && prefix against the scope of ther role so
policy like:
“remove_user_from_project”: “role:project_admin and scope_prefix:project_id”
This starts to get complex and unwieldy however because a single token allows
you to do anything and everything based on your roles. I think we need a
healthy balance between ease of use and the principle of least privilege, so we
might be best to stick to a single scope for each token and force a
reauthentication to do adminy stuff in projectb.
Considering quotas enforcement:
Let's say we wants set the following limits:
* `orga` : max 10 VMs
* ̀ orga.projecta` : max 8 VMs
* `orga.projectb` : max 8 VMs
The idea would be that the `admin` of `orga` wishes to allow 8 VMs to projects
̀`orga.projecta` or `orga.projectb`, but doesn't care how these VMs are spread.
Although he wishes to keep 2 VMs in `orga` for himself.
This seems like a bit of a stretch as a use case. Sharing a set of quotas
across two projects seems strange and if we did have arbitrary nesting you
could do the same by sticking a dummy project in between
orga: max 10
orga.dummy: max 8
orga.dummy.projecta: no max
orga.dummy.projectb: no max
Then to be able to enforce these quotas, Nova (and all other services) would
have to keep track of the tree of quotas, and update the appropriate nodes.
By the way, I'm wondering if it wouldn't be DRYer to centralize the RBAC and
Quotas logic in a unique service (Keystone?). Openstack services (Nova, Cinder,
...) would just have to ask this centralized access management service whether
an action is authorized for a given token?
So I threw out the idea the other day that quota enforcement should perhaps be
done by gantt. Quotas seem to be a scheduling concern more than anything else.
I don't want to take this thread off topic, but I would argue against
this. I don't want a request for a place to put an instance or volume
to mean that an instance or volume has been created with regards to
quotas.
Florent Flament
----- Original Message -----
From: "Vishvananda Ishaya" <vishvana...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Sent: Monday, February 3, 2014 10:58:28 PM
Subject: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy
Discussion
Hello Again!
At the meeting last week we discussed some options around getting true
multitenancy in nova. The use case that we are trying to support can be
described as follows:
"Martha, the owner of ProductionIT provides it services to multiple Enterprise
clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at
SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and
Development teams with many users. Joe needs the ability create users, projects, and
quotas, as well as the ability to list and delete resources across WidgetMaster. Martha
needs to be able to set the quotas for both WidgetMaster and SuperDevShop; manage users,
projects, and objects across the entire system; and set quotas for the client companies
as a whole. She also needs to ensure that Joe can't see or mess with anything owned by
Sam."
As per the plan I outlined in the meeting I have implemented a Proof-of-Concept
that would allow me to see what changes were required in nova to get scoped
tenancy working. I used a simple approach of faking out heirarchy by prepending
the id of the larger scope to the id of the smaller scope. Keystone uses uuids
internally, but for ease of explanation I will pretend like it is using the
name. I think we can all agree that ‘orga.projecta’ is more readable than
‘b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8’.
The code basically creates the following five projects:
orga
orga.projecta
orga.projectb
orgb
orgb.projecta
I then modified nova to replace everywhere where it searches or limits policy
by project_id to do a prefix match. This means that someone using project
‘orga’ should be able to list/delete instances in orga, orga.projecta, and
orga.projectb.
You can find the code here:
https://github.com/vishvananda/devstack/commit/10f727ce39ef4275b613201ae1ec7655bd79dd5f
https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c205c7a3c372412f
Keeping in mind that this is a prototype, but I’m hoping to come to some kind
of consensus as to whether this is a reasonable approach. I’ve compiled a list
of pros and cons.
Pros:
* Very easy to understand
* Minimal changes to nova
* Good performance in db (prefix matching uses indexes)
* Could be extended to cover more complex scenarios like multiple owners or
multiple scopes
Cons:
* Nova has no map of the hierarchy
* Moving projects would require updates to ownership inside of nova
* Complex scenarios involving delegation of roles may be a bad fit
* Database upgrade to hierarchy could be tricky
If this seems like a reasonable set of tradeoffs, there are a few things that
need to be done inside of nova bring this to a complete solution:
* Prefix matching needs to go into oslo.policy
* Should the tenant_id returned by the api reflect the full ‘orga.projecta’,
or just the child ‘projecta’ or match the scope: i.e. the first if you are
authenticated to orga and the second if you are authenticated to the project?
* Possible migrations for existing project_id fields
* Use a different field for passing ownership scope instead of overloading
project_id
* Figure out how nested quotas should work
* Look for other bugs relating to scoping
Also, we need to decide how keystone should construct and pass this information
to the services. The obvious case that could be supported today would be to
allow a single level of hierarchy using domains. For example, if domains are
active, keystone could pass domain.project_id for ownership_scope. This could
be controversial because potentially domains are just for grouping users and
shouldn’t be applied to projects.
I think the real value of this approach would be to allow nested projects with
role inheritance. When keystone is creating the token, it could walk the tree
of parent projects, construct the set of roles, and construct the
ownership_scope as it walks to the root of the tree.
Finally, similar fixes will need to be made in the other projects to bring this
to a complete solution.
Please feel free to respond with any input, and we will be having another
Hierarchical Multitenancy Meeting on Friday at 1600 UTC to discuss.
Vish
On Jan 28, 2014, at 10:35 AM, Vishvananda Ishaya <vishvana...@gmail.com> wrote:
Hi Everyone,
I apologize for the obtuse title, but there isn't a better succinct term to
describe what is needed. OpenStack has no support for multiple owners of
objects. This means that a variety of private cloud use cases are simply not
supported. Specifically, objects in the system can only be managed on the
tenant level or globally.
The key use case here is to delegate administration rights for a group of
tenants to a specific user/role. There is something in Keystone called a
“domain” which supports part of this functionality, but without support from
all of the projects, this concept is pretty useless.
In IRC today I had a brief discussion about how we could address this. I have
put some details and a straw man up here:
https://wiki.openstack.org/wiki/HierarchicalMultitenancy
I would like to discuss this strawman and organize a group of people to get
actual work done by having an irc meeting this Friday at 1600UTC. I know this
time is probably a bit tough for Europe, so if we decide we need a regular
meeting to discuss progress then we can vote on a better time for this meeting.
https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
Please note that this is going to be an active team that produces code. We will
*NOT* spend a lot of time debating approaches, and instead focus on making
something that works and learning as we go. The output of this team will be a
MultiTenant devstack install that actually works, so that we can ensure the
features we are adding to each project work together.
Vish
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
