[openstack-dev] [OpenStack-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-group

Adam Young ayoung at redhat.com
Sat Mar 26 02:48:10 UTC 2016


On 03/25/2016 08:43 AM, nidhi.hada at wipro.com wrote:
>
> Hi All,
>
> A gentle reminder..
>
> Could you please share your thoughts on the approach proposed here ..
>
> https://etherpad.openstack.org/p/access_group_nidhimittalhada
>
> Thanks
>
> Nidhi
>
> *From:* Nidhi Mittal Hada (Product Engineering Service)
> *Sent:* Wednesday, March 09, 2016 2:22 PM
> *To:* 'OpenStack Development Mailing List (not for usage questions)' 
> <openstack-dev at lists.openstack.org>
> *Cc:* 'bswartz at netapp.com' <bswartz at netapp.com>; 'Ben Swartzlander' 
> <ben at swartzlander.org>
> *Subject:* RE: [OpenStack-Dev][Manila] BP 
> https://blueprints.launchpad.net/manila/+spec/access-groups
>
> Hi All,
>
> This is just a gentle reminder to the previous mail ..
>
> PFA is revised doc.
>
> Same is pasted here also.
>
> https://etherpad.openstack.org/p/access_group_nidhimittalhada
>
> Kindly share your thoughts on this..
>
> Thanks
>
> Nidhi
>

Nidhi,


It seems like this is the resource level access control that people have 
been asking for in many projects.  A few thoughts:

Deny rules are tricky.  I would prefer an access control approach that 
denied all by default, and then only allowed explicit adds.


The idea of access groups is much like the roles we have in Keystone.  
With domain specific roles, we have the potential to do some of this, 
but at a courser level.  I wonder if we could unify the approach, such 
that the roles are managed in Keystone, and then could apply to things 
other than items in Manila?

In general, I do not like to have individual users in access lists, 
especially when they might be the only person that can clean up a 
resource, and then they leave.  That means things fall back on "Admin".  
Ideally, all access would be controlled via groups membership.


What you are writing is really similar to the oslo-policy enforcement 
rules.  Are you planning on using Oslo to enforce?

Sorry for jumping in to the middle here, but you did ask for feedback!

> *From:* Nidhi Mittal Hada (Product Engineering Service)
> *Sent:* Friday, February 26, 2016 3:22 PM
> *To:* 'OpenStack Development Mailing List (not for usage questions)' 
> <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> *Cc:* 'bswartz at netapp.com' <bswartz at netapp.com 
> <mailto:bswartz at netapp.com>>; 'Ben Swartzlander' <ben at swartzlander.org 
> <mailto:ben at swartzlander.org>>
> *Subject:* [OpenStack-Dev][Manila] BP 
> https://blueprints.launchpad.net/manila/+spec/access-groups
>
> Hi Manila Team,
>
> I am working on
>
> https://blueprints.launchpad.net/manila/+spec/access-groups
>
> For this I have created initial document as attached with the mail.
>
> It contains DB CLI REST API related changes.
>
> Could you please have a look and share your opinion.
>
> Kindly let me know, if there is some understanding gap,
>
> or something I have missed to document or
>
> share your comments in general to make it better.
>
> *Thank you.*
>
> *Nidhi Mittal Hada*
>
> *Architect | PES / COE*– *Kolkata India*
>
> *Wipro Limited*
>
> *M*+91 74 3910 9883 | *O* +91 33 3095 4767 | *VOIP* +91 33 3095 4767
>
> The information contained in this electronic message and any 
> attachments to this message are intended for the exclusive use of the 
> addressee(s) and may contain proprietary, confidential or privileged 
> information. If you are not the intended recipient, you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately and destroy all copies of this message and any 
> attachments. WARNING: Computer viruses can be transmitted via email. 
> The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage 
> caused by any virus transmitted by this email. www.wipro.com
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160325/9d0e76b5/attachment-0001.html>


More information about the OpenStack-dev mailing list