[Openstack-operators] Dynamic Policy for Access Control
Adam Young
ayoung at redhat.com
Fri Apr 10 21:30:07 UTC 2015
On 04/07/2015 11:36 AM, Marc Heckmann wrote:
> My apologies for not seeing this sooner as the topic is of great
> interest. My comments below inline..
>
> On Mon, 2015-02-23 at 16:41 +0000, Tim Bell wrote:
>>> -----Original Message-----
>>> From: Adam Young [mailto:ayoung at redhat.com]
>>> Sent: 23 February 2015 16:45
>>> To: openstack-operators at lists.openstack.org
>>> Subject: [Openstack-operators] Dynamic Policy for Access Control
>>>
>>> "Admin can do everything!" has been a common lament, heard for multiple
>>> summits. Its more than just a development issue. I'd like to fix that. I think we
>>> all would.
>>>
>>>
>>> I'm looking to get some Operator input on the Dynamic Policy issue. I wrote up a
>>> general overview last fall, after the Kilo summit:
>>>
>>> https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
> I agree with everything in that post.
>
> I would add the following comments:
>
> 1. I doubt this will change, but to be clear, we cannot lose the ability
> to create custom roles and limit the capabilities of the standard roles.
> For example, if I wanted to limit the ability to make images public or
> limit the ability to associate a floating IP.
That is a baseline consideration. We are hoping to make custom roles
the norm.
>
> 2. This work should not be done in vacuum. Ideally, Horizon support for
> assigning roles to users and editing policy should be released at the
> same time or not long after. I realize that this is easier said than
> done, but it will be important in order for the feature to get used.
Role assignments will be done the same way they are now, as Horizon
fetches the list of roles from Keystone.
Editing policy will require a new UI. I don't see that happening in
Horizon until the Keystone mechanism is finalized.
Thanks for the response. We can carry on the conversation at the Summit.
>
>>>
>>> Some of what I am looking at is: what are the general roles that Operators
>>> would like to have by default when deploying OpenStack?
>>>
>> As I described in http://openstack-in-production.blogspot.ch/2015/02/delegation-of-roles.html, we've got (mapped per-project to an AD group)
>>
>> - operator (start/stop/reboot/console)
>> - accounting (read ceilometer data for reporting)
>>
>>> I've submitted a talk about policy for the Summit:
>>> https://www.openstack.org/vote-vancouver/presentation/dynamic-policy-for-
>>> access-control
>>>
>>> If you want, please vote for it, but even if it does not get selected, I'd like to
>>> discuss Policy with the operators at the summit, as input to the Keystone
>>> development effort.
>>>
>> Sounds like a good topic for the ops meetup track.
>>
>>> Feedback greatly welcome.
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
More information about the OpenStack-operators
mailing list