<p dir="ltr">Hi Steve,</p>
<p dir="ltr">Thank you for highlighting the different aspects of it. I'm aware that this is a journey with multiple steps along the way.</p>
<p dir="ltr">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.</p>
<p dir="ltr">How is the cross project blueprint going? Are you getting traction with all PTLs?</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers, <br>
Bruno</p>
<p dir="ltr">Catalyst Cloud<br>
<a href="http://www.catalyst.net.nz/catalyst-cloud">http://www.catalyst.net.nz/catalyst-cloud</a></p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>Hey Bruno,<br><br>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: <a href="http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html" target="_blank">http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html</a><br>Additionally, a few keystone core members have proposed this cross-project spec: <a href="https://review.openstack.org/#/c/245629/" target="_blank">https://review.openstack.org/#/c/245629/</a> - an effort to create a common policy scenario across all projects.<br><br>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!<br><br>Steve Martinelli<br>OpenStack Keystone Project Team Lead<br><br><img width="16" height="16" src="cid:1__=8FBBF5CDDF89A88F8f9e8a93df938690918c8FB@" border="0" alt="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 Cloud"><font color="#424282">Bruno L ---2016/02/18 04:47:13 PM---Hi everyone, I thought I'd pass on feedback from a Catalyst Cloud customer showing how</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Bruno L <<a href="mailto:teolupus.ext@gmail.com" target="_blank">teolupus.ext@gmail.com</a>></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2016/02/18 04:47 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[Openstack] [Keystone] Dynamic RBAC policy please?</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091a5"><br><br><br><font size="4">Hi everyone,<br></font><br><font size="4">I thought I'd pass on feedback from a Catalyst Cloud customer showing how desperate people are for dynamic RBAC.<br><br>---</font><br><br><font size="4">Subject: "kill me now"<br><br>"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 ..."<br><br>---<br></font><br><font size="4">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).<br></font><br><font size="4">We are aware of the work proposed by Adam Young from RedHat (</font><a href="https://review.openstack.org/#/c/279379/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/279379/</font></u></a><font size="4">) and think he is absolutely on the right track. We are even keen to help with the development work related to this blueprint.<br></font><br><font size="4">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.<br></font><br><font size="4">Keen to hear your thoughts about this matter.<br></font><br><font size="4">Cheers,</font><br><font size="4">Bruno<br></font><br><font size="4">Catalyst Cloud</font><br><a href="http://www.catalyst.net.nz/catalyst-cloud" target="_blank"><u><font size="4" color="#0000FF">http://www.catalyst.net.nz/catalyst-cloud</font></u></a><tt>_______________________________________________<br>Mailing list: </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a></tt><tt><br>Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>Unsubscribe : </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a></tt><tt><br></tt><br><br><br>
</p></div>
</div>