Open Stack

I have added my comments to the Etherpad as well (in red in my view of 
the pad). Since I have commented on both Henry and Guang's comments I 
dont want to duplicate everything again in this message

David


On 13/06/2013 14:49, Henry Nash wrote:
> Thanks Guang  - I have added responses, as well as tried to articulate
> the conceptual differences that actually underpin all these approaches.
>   This is in the intro in the etherpad, but reproduced below:
>
> Before looking at the possible solutions, it is worth pointing out that
> the differences in the various options boil down to how we approach two
> conceptual issues:
>
> 1) How should we specify an assignment that applies to more than one
> entity?  There are two conceptual approaches:
> - Use Inheritance, based on some grouping, hopefully one that already
> exists (e.g. use the fact that all projects are owned by a domain)
> - Use a logical expression (e.g. "apply to "*" )
> The differences in these two concepts gets amplified if we want to be
> able, in the future, to further segregate role assignmnets based on some
> other subset (e.g. either hierachy of domains, or 'apply to domains
> matching the string "army*" )
>
> 2) Should you specify the "scope" of the assignment separately from the
> assignment?
> - Keeping them separate is considered good practice by our experts in
> this field, and this can be done by either storing the scope in another
> entity (e.g. the role def) or separatly in the assignment call.
> - If you don't keep them separate, then obviously it is all lumped into
> the assignment call.
>
> The  proposed solutions only differ  fundamentally in how the approach
> these concepts (with consequences in the use cases below), the rest is
> just semantics.
>
> Henry
> On 12 Jun 2013, at 22:46, Yee, Guang wrote:
>
>> Added my comments in the etherpad.
>>
>> ----
>>
>> I really think role assignment merits its own CRUD. Since there's a
>> new API
>> to get the role assignments.
>>
>> GET /role_assignments
>>
>> why not just have the complete API set to facilitate role assignments?
>> That
>> way, we have one unified API for role
>> assignment, as oppose to multiple APIs as exist today.
>>
>> To get a role assignment:
>>
>> GET /role-assignments/{role_assignment_id}
>>
>> To remove a role assignment:
>>
>> DELETE /role-assignments/{role_assignment_id}
>>
>> To create a role assignment:
>>
>> POST /role_assignments
>>
>> {"role_assignment": {
>>    "user" {
>>        "id": user_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>> }
>>
>> Note: "user" and "scope" is similar to the data structure in auth
>> APIs. i.e.
>> can be either "id" or "name" + "domain".
>> If assignment is for a group, just have "group" in there instead of
>> "user".
>> For example,
>>
>> {"role_assignment": {
>>    "group" {
>>        "id": group_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>> }
>>
>> Upon successful creation, a assignment_ref is returned.
>>
>> {"role-assignment": {
>>    "id": role_assignment_id
>>    "user": {
>>        "id": user_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>>    "links": {
>>        "self":
>> "http://localhost:35357/v3/role-assignments/{role_assignment_id}"
>>    }
>> }
>>
>> "scope" is basically the combination and permutation of domains and
>> projects. "domain_id" or "project_id" can be "*" to denote all.
>>
>> Role assignment is really about assigning a given [role] to a given
>> [user or
>> group]
>> for [a given project | a given domain | all projects within a given
>> domain |
>> all projects in all domains | all domains].
>>
>> To assign a given role to a given user or group for [a given project]
>>
>> "scope": {
>>    "project": {
>>        "id": project_id
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all the projects in a
>> given domain]
>>
>> "scope": {
>>    "domain": {
>>        "id": domain_id
>>    },
>>    "project": {
>>        "id": "*"
>>    }
>> }
>>
>> To assign a given role to a given user or group for [a given domain]
>>
>> "scope": {
>>    "domain": {
>>        "id": domain_id
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all the projects
>> in all
>> domains]
>>
>> "scope": {
>>    "domain": {
>>        "id": "*"
>>    },
>>    "project": {
>>        "id": "*"
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all domains]
>>
>> "scope": {
>>    "domain": {
>>        "id": "*"
>>    }
>> }
>>
>>
>> The advantages of role_assignments CRUD are:
>>
>> 1) simplicity (one API for role assignment, instead of multiple)
>> 2) extensible (similiar to the auth API design). Say we need an assignment
>> at the federated level, we can simply add a new scope.
>> 3) consistency (with the auth APIs)
>> 4) RESTful (no need to worry about * in the path)
>>
>>
>>
>> Guang
>>
>> -----Original Message-----
>> From: Tiwari, Arvind
>> Sent: Wednesday, June 12, 2013 9:29 AM
>> To: Henry Nash
>> Cc: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi Henry,
>>
>> Thanks for looking in to my comments, I was trying to raise #3 from your
>> list.  Any ways lets discuss this topic on etherpad from here onwards.
>>
>> Thanks,
>> Arvind
>> ________________________________________
>> From: Henry Nash [henryn at linux.vnet.ibm.com
>> <mailto:henryn at linux.vnet.ibm.com>]
>> Sent: Wednesday, June 12, 2013 10:58 AM
>> To: Tiwari, Arvind
>> Cc: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi
>>
>> So what you have described is correct, in terms of needing multiple
>> roles IF
>> you want one role that only goes to projects and one that doesn't (e.g.
>> maybe goes to just domains). Role explosion was the issue raised against
>> using the role def to hold inheritance behaviour, when it was first
>> discussed.  However, I'd make the following comments:
>>
>> 1) Most services don't need to be concerned about domains, just projects -
>> in fact, today, only keystone understands domains.  Hence there really
>> won't
>> be a role explosion  in terms "Number of Services" x "Multiple roles
>> due to
>> inheritance to projects or domains"
>> 2) In addition, I can imagine than often a cloud provider will create
>>  roles
>> that are project related separate from those that are domain related -
>> they
>> tend to be different people doing those roles (e.g. user_group_admin vs
>> VM_admin etc.), so again, I think there won't be much of any
>> additional role
>> explosion due to the inheritance rules between these roles
>> 3) What there might be, is some role explosions between roles that go
>> to all
>> domains vs roles that go to individual domains - for that, you will need
>> multiple roles.
>> 4) For correctness (since we spend 40 mins on IRC on this :-) ), the
>> "inherited to:" field you use wasn't one of the discussed options - I
>> agree
>> this is not the email to discuss that, but I don't want anyone
>> thinking that
>> the structure below was one we looked at.
>>
>> For all:  The options being discussed are continuing on an etherpad, see:
>> https://etherpad.openstack.org/keystone-role-inheritance.  This
>> contains all
>> the various options being considered, including links to the previous ones
>> we looked at (e.g. not using the role def)
>>
>> Henry
>> On 11 Jun 2013, at 21:18, Tiwari, Arvind wrote:
>>
>> Hi All,
>>
>> Role inheritance is very cool feature and we need this in product, but
>> letting RoleDef to drive the inheritance behavior seem wrong to me as it
>> will cause roleDef explosion and complex policy for services to support.
>>
>> Let's assume a requirement
>>
>> 1.       Cloud admin should have XYZ capability on all the projects, all
>> domains for Sev1. (Global inheritance)
>> 2.       Domain admin should have XYZ capability only on the projects in
>> specific domain for Sev1. (inheritance scoped to a domain)
>>
>> With the current approach (having inherited to in roleDef) we have to have
>> following two roleDefs to support the requirement and hence you have to
>> adjust the policy around these two roleDefs but end result is XYZ
>> capability.
>> {
>>    "role": {
>>        "id": "---id---",
>>        "inheritedTo": "domain=all and project=all", (This means, holder of
>> this role has XYZ capability in all projects in all domains) (Lets not
>> worry
>> about the how we implement it enum / Boolean flag)
>>        "links": {
>>            "self": "http://identity:35357/v3/roles/76e72a"
>>        },
>>        "name": "XYZ-Role-4-cloud-admin"
>>    }
>> }
>>
>> {
>>    "role": {
>>        "id": "---id---",
>>        "inheritedTo": "project=all", (This means, holder of this role has
>> XYZ capability in all projects in specific domain)
>>        "links": {
>>            "self": "http://identity:35357/v3/roles/76e72a"
>>        },
>>        "name": " XYZ-Role-4-domain-admin "
>>    }
>> }
>>
>> Think about growing number of service and above mentioned requirement, we
>> will end up with so many  roleDefs which will have duplicate
>> capability and
>> hence redundant info to maintain in policy. At the same time this solution
>> does not address separation of concerns, we are unnecessary
>> overloading the
>> roleDefs to impose role inheritance behavior which is not its concern. The
>> above mentioned requirement can be easily achievable by single roleDef
>> (may
>> be XYZ-role-Svc1) if we remove inheritedTo concern from roleDef and
>> place it
>> some ware else, role assignment is the right place to address this
>> concern,
>> how that we need to figure out.
>>
>> Let me know if the issue I mentioned looks legitimate.
>>
>>
>> Thanks,
>> Arvind
>>
>> From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
>> Sent: Monday, June 10, 2013 4:30 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi
>>
>> So I ave submitted two new api reviews around this:
>>
>> 1) Defining inherited roles - this is now done on the role def itself, as
>> suggested by David. See: https://review.openstack.org/#/c/29781/12
>> 2) The two un-implmented user/role apis have been replaces with a more
>> flexible way of listing role-assignments.
>> See:https://review.openstack.org/#/c/32394/2
>>
>> I'd like to push to get this nailed asap, so we can have a  shot at
>> getting
>> the code in!
>>
>> Both of these extensions are designed to give us the option to to expand
>> this support for inheritance to all domains in the future if we chose.
>>
>> Henry
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>