<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Is this spec still alive? I'm working on the spec for Ironic integration of Keystone policy, and like some of the items in the draft, but obviously they aren't binding and I can't really reference them unless the spec merges or at least shows progress towards
merging.
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Jay Faulkner</div>
<div class="">OSIC</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 31, 2016, at 6:15 PM, Adam Young <<a href="mailto:ayoung@redhat.com" class="">ayoung@redhat.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">On 01/30/2016 08:24 PM, Henry Nash wrote:<br class="">
</div>
<blockquote cite="mid:B80B246E-E91E-492D-B773-9F95E1E21520@mac.com" type="cite" class="">
<div class=""><br class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 30 Jan 2016, at 21:55, Adam Young <<a moz-do-not-send="true" href="mailto:ayoung@redhat.com" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">On
01/30/2016 04:14 PM, Henry Nash wrote:</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<blockquote type="cite" style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
Hi Adam,<br class="">
<br class="">
Fully support this kind of approach.<br class="">
<br class="">
I am still concerned over the scope check, since we do have examples of when there is more than one (target) scope check, e.g.: an API that might operate on an object that maybe global, domain or project specific - in which case you need to “match up with scope
checks with the object in question”, for example for a given API:<br class="">
<br class="">
If cloud admin, allow the API<br class="">
If domain admin and the object is domain or project specific, then allow the API<br class="">
If project admin and the object is project specific then allow the API<br class="">
<br class="">
Today we can (and do with keystone) encode this in policy rules. I’m not clear how the “scope check in code” will work in this kind of situation.<br class="">
</blockquote>
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">I
originally favored an approach that a user would need to get a token scoped to a resource in order to affect change on that resource, and admin users could get tokens scoped to anything, but I know that makes things harder for Administrators trying to fix
broken deployments. So I backed off on that approach.</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">I
think the right answer would be that the role check would set some value to indicate it was an admin override. So long as the check does not need the actual object from the database, t can perform whatever logic we like.</span><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">The
policy check deep in the code can be as strict or permissive as it desires. If there is a need to re-check the role for an admin check there, policy can still do so. A role check that passes at the Middleware level can still be blocked at the in-code level.</span><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">"If
domain admin and the object is domain or project specific, then allow the API" is trh tricky one, but I don't think we even have a solution for that now. Domain1->p1->p2->p3 type hierarchies don't allow operations on p3 with a token scoped to Domain1.</span><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
So we do actually support things like that, e.g. (from the domain specific role additions):</div>
<div class=""><br class="">
</div>
<div class="">”identity:some_api": role:admin and project_domain_id:%(target.role.domain_id)s (which means I’m project admin and the domain specific role I am going to manipulate is specific to my domain)</div>
<div class=""><br class="">
</div>
<div class="">….and although we don’t have this in our standard policy, you could also write</div>
<div class=""><br class="">
</div>
<div class="">”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s (which means I’m domain admin and I can do some operation on any project in my domain)</div>
</div>
</div>
</div>
</blockquote>
<br class="">
Yeah, we do some things like this in the Keystone policy file, but not in remote services, yet, and it would only work for Domain of the project, not for any arbitrary project in the chain under Domain1: roles on p1 or P2 would have to be inherited in order
to affect any change on resources in 3.<br class="">
<br class="">
<blockquote cite="mid:B80B246E-E91E-492D-B773-9F95E1E21520@mac.com" type="cite" class="">
<div class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class=""><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">I
think that in those cases, I would still favor the user getting a token from Keystone scoped to p3, and use the inherited-role-assignment approach.</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<blockquote type="cite" style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br class="">
Henry<br class="">
<br class="">
<blockquote type="cite" class="">On 30 Jan 2016, at 17:44, Adam Young <<a moz-do-not-send="true" href="mailto:ayoung@redhat.com" class="">ayoung@redhat.com</a>> wrote:<br class="">
<br class="">
I'd like to bring people's attention to a Cross Project spec that has the potential to really strengthen the security story for OpenStack in a scalable way.<br class="">
<br class="">
"A common policy scenario across all projects" <a moz-do-not-send="true" href="https://review.openstack.org/#/c/245629/" class="">
</a><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/245629/">https://review.openstack.org/#/c/245629/</a><br class="">
<br class="">
The summary version is:<br class="">
<br class="">
Role name or pattern Explanation or example<br class="">
-------------------------------------:--------------------------------------------------<br class="">
admin : Overall cloud admin<br class="">
service : for service users only, not real humans<br class="">
{service_type}_admin : identity_admin, compute_admin, network_admin etc.<br class="">
{service_type}_{api_resource}_manager: identity_user_manager,<br class="">
compute_server_manager, network_subnet_manager<br class="">
observer : read only access<br class="">
{service_type}_observer : identity_observer, image_observer<br class="">
<br class="">
<br class="">
Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph Matthews just took it to the next level. It is worth a read.<br class="">
<br class="">
I think this is the way to go. There might be details on how to get there, but the granularity is about right.<br class="">
If we go with that approach, we might want to rethink about how we enforce policy. Specifically, I think we should split the policy enforcement up into two stages:<br class="">
<br class="">
1. Role check. This only needs to know the service and the api resource. As such, it could happen in middleware.<br class="">
<br class="">
2. Scope check: for user or project ownership. This happens in the code where it is currently called. Often, an object needs to be fetched from the database<br class="">
<br class="">
The scope check is an engineering decision: Nova developers need to be able to say where to find the scope on the virtual machine, Cinder developers on the volume objects.<br class="">
<br class="">
Ideally, The python-*clients, Horizon and other tools would be able to determine what capabilities a given token would provide based on the roles included in the validation response. If the role check is based on the URL as opposed to the current keys in the
policy file, the client can determine based on the request and the policy file whether the user would have any chance of succeeding in a call. As an example, to create a user in Keystone, the API is:<br class="">
<br class="">
POST <a moz-do-not-send="true" href="https://hostname:port/v3/users" class="">https://hostname:port/v3/users</a><br class="">
<br class="">
Assuming the client has access to the appropriate policy file, if can determine that a token with only the role "identity_observer" would not have the ability to execute that command. Horizon could then modify the users view to remove the "add user" form.<br class="">
<br class="">
For user management, we want to make role assignments as simple as possible and no simpler. An admin should not have to assign all of the individual roles that a user needs. Instead, assigning the role "Member" should imply all of the subordinate roles that
a user needs to perform the standard workflows. Expanding out the implied roles can be done either when issuing a token, or when evaluating the policy file, or both.<br class="">
<br class="">
I'd like to get the conversation on this started here on the mailing list, and lead in to a really productive set of talks at the Austin summit.<br class="">
<br class="">
<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
</blockquote>
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe:<span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</blockquote>
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">__________________________________________________________________________</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">OpenStack
Development Mailing List (not for usage questions)</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">Unsubscribe:<span class="Apple-converted-space"> </span></span><a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org" style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class="">?subject:unsubscribe</span><br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px;" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
<br class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset> <br class="">
<pre wrap="" class="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br class="">
</div>
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>