Open Stack

On 02/19/2016 08:29 PM, Bruno L wrote:
>
> Hi Steve,
>
> Thank you for highlighting the different aspects of it. I'm aware that 
> this is a journey with multiple steps along the way.
>
> From what we can see here in New Zealand, these are the kind of 
> features that would propel the adoption of OpenStack by larger 
> organisations.
>
> How is the cross project blueprint going? Are you getting traction 
> with all PTLs?
>
> I wonder if a few mid-cycle meetings between the TC and PTLs would be 
> useful to facilitate and ensure progress on important cross-project 
> features like this.
>


It is a bit late for midcycles, but certainly on the top of the list for 
the Austin summit.

I see RBAC going toward three tiers of roles:

The role you are assigned in your organization:  call this your position
The workflows you need to get done to perform the obligations of your 
position:
The permissions you need to perform a specific workflow.

With implied roles, we can start building this structure.

I think the trickiest part to get right is going to be the lowest 
level.   year or so ago, I pushed for unified policy file, and got a lot 
of push back.  The ensuing discussions lead to two epiphanies:

1.  Matching the scope of the token to the scope of the resource (VM, 
Network, image etc) is an engineering effort, and should be managed by 
the core team.

2.  There is a certain base assumption about who should be performing an 
action:  admin versus member.  The core teams want to be able to set the 
expectation for an API accordingly.


However, my original reason for wanting a unified policy file stills 
stands:  we need an overall inventory of API/Policy enforcement points 
to be able to build up the overall structure.


> Cheers,
> Bruno
>
> Catalyst Cloud
> http://www.catalyst.net.nz/catalyst-cloud
>
> Hey Bruno,
>
> Dynamic policy is just one aspect of the issues keystone has with 
> authorization. We've also recently merged `implied roles`, which can 
> be seen here: 
> http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html
> Additionally, a few keystone core members have proposed this 
> cross-project spec: https://review.openstack.org/#/c/245629/ - an 
> effort to create a common policy scenario across all projects.
>
> What I'm trying to convey is that we know there are shortcomings, it's 
> on our radar and we're trying to solve them. Feedback from operators 
> is paramount for us to make the right changes, so feel free to review 
> the new cross-project spec as well!
>
> Steve Martinelli
> OpenStack Keystone Project Team Lead
>
> Inactive hide details for Bruno L ---2016/02/18 04:47:13 PM---Hi 
> everyone, I thought I'd pass on feedback from a Catalyst CloudBruno L 
> ---2016/02/18 04:47:13 PM---Hi everyone, I thought I'd pass on 
> feedback from a Catalyst Cloud customer showing how
>
> From: Bruno L <teolupus.ext at gmail.com <mailto:teolupus.ext at gmail.com>>
> To: openstack <openstack at lists.openstack.org 
> <mailto:openstack at lists.openstack.org>>
> Date: 2016/02/18 04:47 PM
> Subject: [Openstack] [Keystone] Dynamic RBAC policy please?
>
> ------------------------------------------------------------------------
>
>
>
> Hi everyone,
>
> I thought I'd pass on feedback from a Catalyst Cloud customer showing 
> how desperate people are for dynamic RBAC.
>
> ---
>
> Subject: "kill me now"
>
> "Sometimes Openstack just seems half-baked.  None of the ACL / IAM we 
> need for an enterprise solution is actually there, so I'm resorting to 
> splitting things across multiple accounts, but then I run into 
> problems when I want something like private ..."
>
> ---
>
> I don't know how other cloud service providers feel about this topic, 
> but here in New Zealand we have several customers (in particular large 
> ones) needing more granular access control. Ultimately customers want 
> to be able to define their own roles and policies, ideally to a very 
> granular level (eg: Application X role allows user to perform all 
> actions on compute instance with ID 1234).
>
> We are aware of the work proposed by Adam Young from RedHat 
> (_https://review.openstack.org/#/c/279379/_) and think he is 
> absolutely on the right track. We are even keen to help with the 
> development work related to this blueprint.
>
> My main concern here is that such a change requires coordinated effort 
> across all projects to adopt the new dynamic RBAC mechanism. The key 
> word here is "coordinated", because from a governance point of view I 
> think OpenStack is lacking a few mid-cycle meetings where all PTLs and 
> TCs agree on a handful of cross-project blueprints that are essential 
> to advance OpenStack and ensure that all project teams working on them.
>
> Keen to hear your thoughts about this matter.
>
> Cheers,
> Bruno
>
> Catalyst Cloud
> _http://www.catalyst.net.nz/catalyst-cloud________________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org 
> <mailto:openstack at lists.openstack.org>
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160222/34f639cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160222/34f639cd/attachment.gif>