<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/19/2016 08:29 PM, Bruno L wrote:<br>
</div>
<blockquote
cite="mid:CAOXScJsi510DPTatQqueC=SiwrrkAAsUhTxfg84dwQyr3oiGVg@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
<br>
It is a bit late for midcycles, but certainly on the top of the list
for the Austin summit. <br>
<br>
I see RBAC going toward three tiers of roles:<br>
<br>
The role you are assigned in your organization: call this your
position<br>
The workflows you need to get done to perform the obligations of
your position:<br>
The permissions you need to perform a specific workflow.<br>
<br>
With implied roles, we can start building this structure.<br>
<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAOXScJsi510DPTatQqueC=SiwrrkAAsUhTxfg84dwQyr3oiGVg@mail.gmail.com"
type="cite">
<p dir="ltr">Cheers, <br>
Bruno</p>
<p dir="ltr">Catalyst Cloud<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 src="cid:part4.07090507.00010207@redhat.com"
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" height="16" width="16" border="0"><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</p>
<hr style="color:#8091a5" size="2" noshade="noshade"
width="100%" align="left"><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:openstack@lists.openstack.org"
target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : </tt><tt><a moz-do-not-send="true"
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>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
</pre>
</blockquote>
<br>
</body>
</html>