Open Stack

Services already own their own policy enforcement, and therefore own their
own definitions of roles. A service deployment can already require roles
that are prefixed by a specific string (compute-*), and can already map
actual capabilities onto those roles ({"compute-create":
"role:compute-manager"}).

Centralizing or duplicating some aspect of that enforcement into keystone
does nothing for OpenStack, AFAICT.

At this point, if you've somehow changed your proposal as the message below
implies, I'd appreciate a summary of the revision that addresses the
questions and issues that have repeatedly been raised against it and
ignored.


On Wed, Dec 18, 2013 at 11:19 AM, Tiwari, Arvind <arvind.tiwari at hp.com>wrote:

>  Hi Adam,
>
>
>
> I would like to request you to revisit the below link and provide your
> opinion, so that we can move forward and try to find a common ground where
> everyone.
>
>
>
> https://review.openstack.org/#/c/61897
>
>
>
>
>
> *Below is my justification for service_id in role model:*
>
> In a public cloud deployment model, service teams (or service deployers)
> defines the roles along with other artifacts (service and endpoint) and
> they need full control on these artifacts including roles. This way they
> can control the life cycle of these artifacts without depending on IAM
> service providers. (more details in
> https://blueprints.launchpad.net/keystone/+spec/name-spaced-roles)
>
> As an IAM service provider in a public cloud deployment, it is our
> responsibility to facilitate them so that they can control full life cycle
> of their service specific artifacts. To make it happen we need tight access
> control on these artifacts, so that a service deployer accidently or
> maliciously not able to mess-up with other services.
>
> To achieve that level fine granularity and to isolate service deployers
> from artifacts, we need to associate entity models (service, endpoints and
> roles) with a service.  This way we can define entity ownership and define
> access control policy based on service. Currently, role data model  does
> not support any association and that is why I am requesting  to introduce
> some way to associate a role with domain, project and service. This
> association also helps to define a namespace for making the role name
> globally unique.
>
>
>
> Previously I was trying achieve tight linking of roles with service_id and
> that might be offending for some community members. Now after much effort
> and help from David Chadwick, we have generalized the role model and come
> up with generic design, so that it can fit in with every once use case. As
> I mentioned in the spec it will be backward compatible so that it won’t
> break the existing deployments
>
>
>
> I would appreciate if you can revisit the link and provide comments and
> suggestions, there might be still some room for improvements and I am open
> for them.
>
>
>
>
>
> Dolph, I would also like you to review the specs, so that we can make some
> progress.
>
>
>
>
>
> Regards,
>
> Arvind
>
>
>
>
>
>
>
>
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/00fdaf2c/attachment.html>