On 08/05/2015 12:01 PM, Kris G. Lindgren wrote:
We ran into this as well.
What we did is create an external to keystone api, that we expose to our
end users via a UI. The api will let user create projects (with a
specific defined quota) and also add users with the "project admins" role
to the project. Those admins can add/remove users from the project and
also delete the project. You can also be a "member", where you have the
ability to spin up vm's under the project but not add/remove users or
remove the project. We also do some other stuff to clean up items in a
project before its deleted. We are working to move this functionality out
of the current external API and into keystone. I believe we were going to
look at waffle-haus to add a paste filter to intercept the project create
calls and do the needful.
We also modified the policy.json files for the services that we care about
to add the new roles that we created.
Were you working around limitation by building an external system to
Keystone to provide a means of delegating the ability to assign roles?
Would you have wanted to synchronize the roles you defined in your
Keytone instance with the policy files directly? Did you have to modify
policy files beyond the Keystone policy file?
____________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.
On 8/5/15, 9:39 AM, "Fox, Kevin M" <kevin....@pnnl.gov> wrote:
As an Op, I've ran into this problem and keep running into it. I would
very much like a solution.
Its also quite related to the nova instance user issue I've been working
on, that's needed by the App Catalog project.
So, yes, please keep fighting the good fight.
Thanks,
Kevin
________________________________________
From: Adam Young [ayo...@redhat.com]
Sent: Wednesday, August 05, 2015 7:50 AM
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] Dynamic Policy
How do you delegate the ability to delegate?
Lets say you are running a large cloud (purely hypothetical here) and
you want to let a user manage their own project. They are "admin" but
they should be able to invite or eject people.
In order to do this, an ordinary user needs to be able to make a role
assignment. However, Keystone does not support this today: if you are
admin somewhere, you are admin everywhere:
https://bugs.launchpad.net/keystone/+bug/968696
Access control in OpenStack is controlled by Policy. An informal survey
of operators shows that most people run with the stock policies such as
the Nova policy:
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json
In order to scope admin to the proejct, we would need to have rules that
enforce this scoping: Evey rule should check that the project_id in the
token provided matches the project_id of the resource of the API.
If we manage to get the policy files rewritten this way, We then need a
way to limit what roles a user can assign. The default mechanism
would say that a user needs to have an administrative role on the
project (or domain) that they want to assign the role on.
I don't think anything I've written thus far is controversial. Then, why
has it not happened yet? here are the list of problems we need to solve:
1. Operators expect the existing policy files to work as is. Changing
them will break workflow.
2. If everything is scoped, we need a way to delete resources left
orphan when a project is deleted from Keystone and the service does not
get the notification (or know how to handle it).
Of the two, I think the top one is the more difficult to solve. Scoping
everything can be handled via one of two mechanism; either allow a
power-admin user to get a token scoped to some random project (even if
it has been deleted) or allow a token scoped to an administrative
project to also delete resources for a random project.
Dealing with the existing policy file issues is trickier, and that is
the real reason for the Dynamic Policy approach: give the endpoints
the ability to fetch their policy files from Keystone. If policy goes
>from being a configuration file to data, it is managed outside of the
configuration management tools, and becomes much more fluid. This has
risks, and should be an Opt-In mechanism.
Fetching the policy files from Keystone also provides the start of a
richer set of management for policy rules. Currently, each of the stock
policy files exists only in their seperate git repos. There is no
sharing of policy rules across projects. If the policy files were
managed, rule by rule, from a centralized repository, rules could be
shared, providing, among other things, the ability to enforce
hierarchical roles, roles namespaced to a service, and other, richer
policy management.
Feedback on this approach from operators is greatly appreciated. I need
to justify the effort that would go in to making this happen, so if you
want it, speak up.
If, on the other hand, you feel that this is needlessly complicated or
would make deployments more difficult, that is important too, and please
let me know.
Finally, if you can see some alternative methods of implementing a more
dynamic access control, please chime in.
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
