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