<div dir="ltr">Thank you Lance for this really useful big picture.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 13 mars 2019 à 19:50, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<tt>Thanks to Ben for looping keystone into this discussion and
providing some initial details. More comments inline below.</tt><br>
<br>
<div class="gmail-m_1918026707081480472moz-cite-prefix">On 3/13/19 1:00 PM, Herve Beraud wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le mer. 13 mars 2019
à 18:33, Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tagging Keystone as I
think they are better suited to answering this.<br>
</blockquote>
<div><br>
</div>
<div>Yep make sense :) <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A bit more from my limited knowledge inline.<br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 3/13/19 12:07 PM, Herve Beraud wrote:<br>
> Hello<br>
> <br>
> ## Overview<br>
> I want to bring up this topic (admin-ness not
properly scoped)[1] to get <br>
> a big picture of the state of this issue and that was
needed on the <br>
> oslo.policy side.<br>
> <br>
> Few weeks ago some RHOSP customers request for an
enhancement of <br>
> oslo.policy since their admin domain can manage other
domains. They use <br>
> OSP13.<br>
<br>
For those not rocking fedoras, OSP 13 corresponds to
Queens. :-)<br>
<br>
> <br>
> The goal of this ML thread is to help us to track
informations about <br>
> this topic and I also planned to discuss about this
topic during the <br>
> next oslo meeting (Monday 18 of March).<br>
> <br>
> ## Details<br>
> <br>
> After some investigations I've found a lot of related
issues on <br>
> launchpad[1][2][3], and a lot of disucssions inside
the openstack <br>
> community about this topic.<br>
> <br>
> First I guess it's not an RFE but it's a known issue.<br>
> <br>
> This bug has side-effects across several services,
not just oslo or <br>
> keystone, making the fix complex to orchestrate
across services.<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
Yup... Regardless of how we write or develop things in keystone, we
have to be good ambassadors to the services looking to consume this
work. There have been past proposals to pull *all* policy
enforcement and decisions into keystone, but that's prone to
performance issues and might hinder development pace for other teams
(depending on the implementation).<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> In a first time, I want to know more about the latest
events on this <br>
> topic on the oslo side:<br>
> - the states of the related specs <br>
> (<a href="https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html</a>).<br>
> - if we need to add more changes to completely fix
this issue and/or if <br>
> everything is complete on the oslo side and know
since which version. I <br>
> guess this one[4] is related to.<br>
<br>
To my knowledge the Oslo side is done. I think we actually
added the <br>
necessary fields to oslo.policy (and oslo.context?) at the
end of last <br>
cycle. I'm not sure where the Keystone side stands, but
I'm sure someone <br>
from that team can provide an update.<br>
</blockquote>
<div><br>
</div>
<div>Yeah I guess we can bring oslo.context too since these
changes like looks to this topic too:</div>
<div> <a href="https://github.com/openstack/oslo.context/commit/f65408df5cd5924f2879c3ee94d07fd27cb2cf73" target="_blank">https://github.com/openstack/oslo.context/commit/f65408df5cd5924f2879c3ee94d07fd27cb2cf73</a><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
As Ben noted, everything client/library-wise is done.<br>
<br>
To be verbose:<br>
<br>
- keystone implemented support for users and groups to have system
role assignments in Queens [0][1], along with the ability for users
to generate system-scoped tokens<br>
- keystoneauth implemented support for building system-scoped
authentication requests [2]<br>
- python-keystoneclient has support for managing system role
assignments just like you'd manage project or domain role
assignments [3]<br>
- so does python-openstackclient [4]<br>
- keystonemiddleware knows what system-scoped tokens are and
populates request headers properly [5] (this is important for
services to consume system-scoped tokens)<br>
- services using oslo.context can generate RequestContext objects
from request environments and oslo.context will handle the
appropriate attributes if the request was made with a system-scoped
token [6] (making consumption even easier)<br>
- oslo.policy actually knows how to understand RequestContext
objects from oslo.context, making the whole authorization code
across services simpler (since services shouldn't have to build
credential dictionaries with system scope set in a particular way)
[7]<br>
- finally, in Rocky keystone formally added support for default
roles, which are available for services to write default policies
for [8]<br>
<br>
Long story short, all the plumbing should be in place for services
to start consuming system-scoped tokens to protect API accordingly.<br>
<br>
[0]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html" target="_blank">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html</a><br>
[1]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/q/topic:bp/system-scope+project:openstack/keystone+status:merged" target="_blank">https://review.openstack.org/#/q/topic:bp/system-scope+project:openstack/keystone+status:merged</a><br>
[2] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/529665/" target="_blank">https://review.openstack.org/#/c/529665/</a><br>
[3] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/524415/" target="_blank">https://review.openstack.org/#/c/524415/</a><br>
[4] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/524416/" target="_blank">https://review.openstack.org/#/c/524416/</a><br>
[5] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/564072/" target="_blank">https://review.openstack.org/#/c/564072/</a><br>
[6] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/530509/" target="_blank">https://review.openstack.org/#/c/530509/</a><br>
[7] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/578995/" target="_blank">https://review.openstack.org/#/c/578995/</a><br>
[8]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html" target="_blank">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html</a><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Unfortunately, even if Keystone is completely finished, to
consume this <br>
I _think_ it's going to require policy changes in all of
the consuming <br>
services, and I don't know that any of those have happened
yet. I <br>
believe it's a PTG topic for Keystone.<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
Yes to both.<br>
<br>
(first yes)<br>
<br>
We have time set aside during the forum and the PTG to talk about
this [9]. The forum session should be more operator specific, so we
can answer questions and share knowledge the best we can. We're
hoping the PTG session will be developer focused, where we can walk
through how services can get from point A to point B (point A being
whatever they're doing with policy today that doesn't fall inline
with admin-ness and point B being everything enforced at the proper
scope allowing more functionality to be exposed to more users).<br>
<br>
(second yes)<br>
<br>
Despite keystone being the authorization and authentication service,
it's not exempt from these issues or having to consume system scope
itself. The team dedicated a bunch of time in Stein to work on this.
We certainly encourage other projects to do the same, but we're also
hoping to share what experiences we built up in keystone so that it
will be easier for other teams. I provided a summary on the status
of the keystone-specific work last week [10], including the process
we used for breaking everything down. It's apparent that despite the
work we've done here, there are still a lot of knowledge gaps in how
to actually consume all this stuff, not to mention the overall
concept of scopes. We have a document up for review to fix that, too
[11][12].<br>
<br>
[9] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://etherpad.openstack.org/p/DEN-keystone-forum-sessions" target="_blank">https://etherpad.openstack.org/p/DEN-keystone-forum-sessions</a><br>
[10]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003552.html" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003552.html</a>
warning: this is a glorious wall of text<br>
[11] <a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/c/638563/" target="_blank">https://review.openstack.org/#/c/638563/</a><br>
[12]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="http://logs.openstack.org/63/638563/9/check/openstack-tox-docs/44b339a/html/contributor/services.html#why-are-authorization-scopes-important" target="_blank">http://logs.openstack.org/63/638563/9/check/openstack-tox-docs/44b339a/html/contributor/services.html#why-are-authorization-scopes-important</a>
(rendered version)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Also due to the complexity of this issue I guess is
not totally fixed on <br>
> the whole openstack components on stein and it can't
be fully (whole) <br>
> backported to stable branches, but your point of view
is really <br>
> appreciate. In other words I guess some parts are
already fixed on some <br>
> components but some services still need to be fixed
and the issue <br>
> partially occur on stein, so fix that on stable
branches is not really <br>
> possible, can you confirm?<br>
<br>
Yeah, I don't expect most of this would be backportable,
especially all <br>
the way to Queens.<br>
</blockquote>
<div><br>
</div>
<div>Thanks. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Correct. The plumbing alone was spread across 8 different
repositories, some of which were libraries. This doesn't include the
100+ patches to keystone that include extensive protection tests or
updated policies [13] * to fix our own APIs *.<br>
<br>
[13]
<a class="gmail-m_1918026707081480472moz-txt-link-freetext" href="https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:implement-default-roles" target="_blank">https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:implement-default-roles</a><br>
* My intention isn't to scare anyone off from tackling this work,
but I do want to be upfront in how we approached the problem and how
we're addressing it. I think teams will need that information in
order to size tasks appropriately and set realistic expectations.
For what it's worth, I think the way we broke things down made
everything a lot easier for people to chip in and contribute. At the
very least, it gave us the opportunity to air out the issue instead
of tracking *all* of it against 968696.<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Also I've found few related specs that I guess can be
useful to track <br>
> the evolution:<br>
> - <br>
> <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html</a><br>
> - <br>
> <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html</a><br>
> - <br>
> <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html</a><br>
> - <br>
> <a href="https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html</a><br>
> <br>
> If I missed something useful do not hesitate to reply
on and to share it <br>
> with us.<br>
> <br>
> [1] <a href="https://bugs.launchpad.net/keystone/+bug/968696" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/968696</a><br>
> [2] <a href="https://bugs.launchpad.net/keystone/+bug/1783659" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/1783659</a><br>
> [3] <a href="https://bugs.launchpad.net/nova/+bug/1649532" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1649532</a><br>
> [4] <a href="https://bugs.launchpad.net/oslo.policy/+bug/1577996" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.policy/+bug/1577996</a><br>
> <br>
> -- <br>
> Hervé Beraud<br>
> Senior Software Engineer<br>
> Red Hat - Openstack Oslo<br>
> irc: hberaud<br>
> -----BEGIN PGP SIGNATURE-----<br>
> <br>
>
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>
>
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>
>
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>
>
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>
>
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>
>
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>
>
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>
>
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>
>
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>
>
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>
>
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>
> v6rDpkeNksZ9fFSyoY2o<br>
> =ECSj<br>
> -----END PGP SIGNATURE-----<br>
> <br>
<br>
</blockquote>
</div>
<br clear="all">
<br>
-- <br>
<div dir="ltr" class="gmail-m_1918026707081480472gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Hervé Beraud</div>
<div>Senior Software Engineer<br>
</div>
<div>Red Hat - Openstack Oslo</div>
<div>irc: hberaud</div>
<div>-----BEGIN PGP SIGNATURE-----<br>
<br>
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>
v6rDpkeNksZ9fFSyoY2o<br>
=ECSj<br>
-----END PGP SIGNATURE-----<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer<br></div><div>Red Hat - Openstack Oslo</div><div>irc: hberaud</div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div>