Hi Adam
I think in the context of RBAC, President is only a role if all
resources recognise it as such and assign it permissions, which in
general they do not, so its not a useful role - it would have no
permissions. OTOH, President of the USA, President of Brazil and
President of Chile are separate roles with separate permissions. In the
context of OpenStack, admin of swift is a different role to admin of
keystone and therefore they should be clearly defined roles (not the
same one). What the current OpenStack system has done is try to short
circuit this by saying there is a single admin role and this is attached
to different projects and different resources, but it is the same role,
only when it is attached to different things it has different
permissions. The model would be much clearer in my opinion if each role
was clearly identified as such, and then each role could be assigned to
users as required and given it own unique set of permissions.
regards
David
On 19/06/2013 19:11, Adam Young wrote:
On 06/19/2013 01:14 PM, David Chadwick wrote:
Hi Adam
as I said in a previous post (to which Henry replied "but
unfortunately that is not the way Keystone currently works" my
paraphrase), we should not even be assigning roles to users to
projects, as this is mixing up user-role assignments and
permission-role assignments. We/keystone should simply be assigning
roles to users. The service will then assign the permissions to the
roles that it wants to, and I am sure that most of the complexity you
are now trying to grapple with will go away, because there will be no
limitations on where the roles can be used. Its up to the service to
decide if a role has permissions or not.
So, a project is a scope of a role, as is a domain. Unless the role
becomes a de factor tuple of "role_project" I don't see how we can
acheive a scalable RBAC system anyway. President is a role, but you
have to be President of the United States in order to get on Air Force One.
Another way to put it is that we are just assigning a set of roles to a
user. We just decide which set of roles to assign a-priori before they
get to the service, by having them state which project they plan on
using the token for, and the appropriate set of roles is assigned.
If we were to go with the full blown Attribute Based Access control, we
would still be faced with the same problem. The end-to-end problem is
:from the attributes that the user has what set of actions can the user
perform. The Keystone abstraction is to make a middle layer: roles
within projects. We've scoped keystone responsibilities down to
figuring out how to assign these.
I am currently splitting the assignments backend from identity, and that
is going to be essential to any forward movement toward a reasonable
Keystone architecture. Let me post it as a work in progress so you can
see where I am headed, and we can discuss. I'd rather not have to deal
with rebasing a bunch of changes for a one-off solution to the overall
problem when we are much closer to a general solution than we realize.
I appreciate that this is not the way that Keystone currently works,
and you may not have time to change it for Havana, but rather than
trying to add more complexity to solve its current skewed model, why
not try to advance down an alternative path that veers towards the
classical clean RBAC model and simplification of the role assignment
problem? And target on Ice for the introduction of the revised model
regards
David
On 19/06/2013 15:36, Adam Young wrote:
So I'd like to redefine the problem definition here:
"Provide a mechanism by which role assignments can be specified for more
than one project."
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
