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 <[email protected] <mailto:[email protected]>>
To: openstack <[email protected]
<mailto:[email protected]>>
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 : [email protected]
<mailto:[email protected]>
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
