Open Stack

Thanks to Ben for looping keystone into this discussion and providing
some initial details. More comments inline below.

On 3/13/19 1:00 PM, Herve Beraud wrote:
>
>
> Le mer. 13 mars 2019 à 18:33, Ben Nemec <openstack at nemebean.com
> <mailto:openstack at nemebean.com>> a écrit :
>
>     Tagging Keystone as I think they are better suited to answering this.
>
>
> Yep make sense :)
>  
>
>     A bit more from my limited knowledge inline.
>
>
>     On 3/13/19 12:07 PM, Herve Beraud wrote:
>     > Hello
>     >
>     > ## Overview
>     > I want to bring up this topic (admin-ness not properly
>     scoped)[1] to get
>     > a big picture of the state of this issue and that was needed on the
>     > oslo.policy side.
>     >
>     > Few weeks ago some RHOSP customers request for an enhancement of
>     > oslo.policy since their admin domain can manage other domains.
>     They use
>     > OSP13.
>
>     For those not rocking fedoras, OSP 13 corresponds to Queens. :-)
>
>     >
>     > The goal of this ML thread is to help us to track informations
>     about
>     > this topic and I also planned to discuss about this topic during
>     the
>     > next oslo meeting (Monday 18 of March).
>     >
>     > ## Details
>     >
>     > After some investigations I've found a lot of related issues on
>     > launchpad[1][2][3], and a lot of disucssions inside the openstack
>     > community about this topic.
>     >
>     > First I guess it's not an RFE but it's a known issue.
>     >
>     > This bug has side-effects across several services, not just oslo or
>     > keystone, making the fix complex to orchestrate across services.
>

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).

>     >
>     > In a first time, I want to know more about the latest events on
>     this
>     > topic on the oslo side:
>     > - the states of the related specs
>     >
>     (https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html).
>     > - if we need to add more changes to completely fix this issue
>     and/or if
>     > everything is complete on the oslo side and know since which
>     version. I
>     > guess this one[4] is related to.
>
>     To my knowledge the Oslo side is done. I think we actually added the
>     necessary fields to oslo.policy (and oslo.context?) at the end of
>     last
>     cycle. I'm not sure where the Keystone side stands, but I'm sure
>     someone
>     from that team can provide an update.
>
>
> Yeah I guess we can bring oslo.context too since these changes like
> looks to this topic too:
> https://github.com/openstack/oslo.context/commit/f65408df5cd5924f2879c3ee94d07fd27cb2cf73

As Ben noted, everything client/library-wise is done.

To be verbose:

- 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
- keystoneauth implemented support for building system-scoped
authentication requests [2]
- python-keystoneclient has support for managing system role assignments
just like you'd manage project or domain role assignments [3]
- so does python-openstackclient [4]
- keystonemiddleware knows what system-scoped tokens are and populates
request headers properly [5] (this is important for services to consume
system-scoped tokens)
- 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)
- 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]
- finally, in Rocky keystone formally added support for default roles,
which are available for services to write default policies for [8]

Long story short, all the plumbing should be in place for services to
start consuming system-scoped tokens to protect API accordingly.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[1]
https://review.openstack.org/#/q/topic:bp/system-scope+project:openstack/keystone+status:merged
[2] https://review.openstack.org/#/c/529665/
[3] https://review.openstack.org/#/c/524415/
[4] https://review.openstack.org/#/c/524416/
[5] https://review.openstack.org/#/c/564072/
[6] https://review.openstack.org/#/c/530509/
[7] https://review.openstack.org/#/c/578995/
[8]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html

>  
>
>
>     Unfortunately, even if Keystone is completely finished, to consume
>     this
>     I _think_ it's going to require policy changes in all of the
>     consuming
>     services, and I don't know that any of those have happened yet. I
>     believe it's a PTG topic for Keystone.
>

Yes to both.

(first yes)

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).

(second yes)

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].

[9] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
[10]
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003552.html 
warning: this is a glorious wall of text
[11] https://review.openstack.org/#/c/638563/
[12]
http://logs.openstack.org/63/638563/9/check/openstack-tox-docs/44b339a/html/contributor/services.html#why-are-authorization-scopes-important
(rendered version)

>
>     >
>     > Also due to the complexity of this issue I guess is not totally
>     fixed on
>     > the whole openstack components on stein and it can't be fully
>     (whole)
>     > backported to stable branches, but your point of view is really
>     > appreciate. In other words I guess some parts are already fixed
>     on some
>     > components but some services still need to be fixed and the issue
>     > partially occur on stein, so fix that on stable branches is not
>     really
>     > possible, can you confirm?
>
>     Yeah, I don't expect most of this would be backportable,
>     especially all
>     the way to Queens.
>
>
> Thanks.

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 *.

[13]
https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:implement-default-roles
* 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.


>
>     >
>     > Also I've found few related specs that I guess can be useful to
>     track
>     > the evolution:
>     > -
>     >
>     https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html
>     > -
>     >
>     https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html
>     > -
>     >
>     https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
>     > -
>     >
>     https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html
>     >
>     > If I missed something useful do not hesitate to reply on and to
>     share it
>     > with us.
>     >
>     > [1] https://bugs.launchpad.net/keystone/+bug/968696
>     > [2] https://bugs.launchpad.net/keystone/+bug/1783659
>     > [3] https://bugs.launchpad.net/nova/+bug/1649532
>     > [4] https://bugs.launchpad.net/oslo.policy/+bug/1577996
>     >
>     > --
>     > Hervé Beraud
>     > Senior Software Engineer
>     > Red Hat - Openstack Oslo
>     > irc: hberaud
>     > -----BEGIN PGP SIGNATURE-----
>     >
>     > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
>     > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
>     > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
>     > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
>     > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
>     > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
>     > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
>     > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
>     > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
>     > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
>     > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
>     > v6rDpkeNksZ9fFSyoY2o
>     > =ECSj
>     > -----END PGP SIGNATURE-----
>     >
>
>
>
> -- 
> Hervé Beraud
> Senior Software Engineer
> Red Hat - Openstack Oslo
> irc: hberaud
> -----BEGIN PGP SIGNATURE-----
>
> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
> v6rDpkeNksZ9fFSyoY2o
> =ECSj
> -----END PGP SIGNATURE-----
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190313/cab14f98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190313/cab14f98/attachment-0001.sig>