<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 01/30/2016 08:24 PM, Henry Nash
wrote:<br>
</div>
<blockquote cite="mid:B80B246E-E91E-492D-B773-9F95E1E21520@mac.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div><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 class="moz-txt-link-abbreviated" href="mailto:ayoung@redhat.com">ayoung@redhat.com</a></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>
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>
<br>
<blockquote cite="mid:B80B246E-E91E-492D-B773-9F95E1E21520@mac.com"
type="cite">
<div>
<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 class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/245629/">https://review.openstack.org/#/c/245629/</a></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 class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a></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 class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a></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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
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>
</body>
</html>