Re: [Openstack-operators] Dynamic Policy for Access Control

2015-04-10 Thread Adam Young

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 +, Tim Bell wrote:

-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: 23 February 2015 16:45
To: openstack-operators@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@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


Re: [Openstack-operators] Dynamic Policy for Access Control

2015-04-07 Thread Marc Heckmann
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 +, Tim Bell wrote:
  -Original Message-
  From: Adam Young [mailto:ayo...@redhat.com]
  Sent: 23 February 2015 16:45
  To: openstack-operators@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.

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.

  
  
  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@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