Open Stack

On 08/22/2018 07:49 AM, Lance Bragstad wrote:
>
> On 08/22/2018 03:23 AM, Adrian Turjak wrote:
>> Bah! I saw this while on holiday and didn't get a chance to respond,
>> sorry for being late to the conversation.
>>
>> On 11/08/18 3:46 AM, Colleen Murphy wrote:
>>> ### Self-Service Keystone
>>>
>>> At the weekly meeting Adam suggested we make self-service keystone a focus point of the PTG[9]. Currently, policy limitations make it difficult for an unprivileged keystone user to get things done or to get information without the help of an administrator. There are some other projects that have been created to act as workflow proxies to mitigate keystone's limitations, such as Adjutant[10] (now an official OpenStack project) and Ksproj[11] (written by Kristi). The question is whether the primitives offered by keystone are sufficient building blocks for these external tools to leverage, or if we should be doing more of this logic within keystone. Certainly improving our RBAC model is going to be a major part of improving the self-service user experience.
>>>
>>> [9] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-121
>>> [10] https://adjutant.readthedocs.io/en/latest/
>>> [11] https://github.com/CCI-MOC/ksproj
>> As you can probably expect, I'd love to be a part of any of these
>> discussions. Anything I can nicely move to being logic directly
>> supported in Keystone, the less I need to do in Adjutant. The majority
>> of things though I think I can do reasonably well with the primitives
>> Keystone gives me, and what I can't I tend to try and work with upstream
>> to fill the gaps.
>>
>> System vs project scope helps a lot though, and I look forward to really
>> playing with that.
> Since it made sense to queue incorporating system scope after the flask
> work, I just started working with that on the credentials API*. There is
> a WIP series up for review that attempts to do a couple things [0].
> First it tries to incorporate system and project scope checking into the
> API. Second it tries to be more explicit about protection test cases,
> which I think is going to be important since we're adding another scope
> type. We also support three different roles now and it would be nice to
> clearly see who can do what in each case with tests.
>
> I'd be curious to get your feedback here if you have any.
>
> * Because the credentials API was already moved to flask and has room
> for self-service improvements [1]
>
> [0] https://review.openstack.org/#/c/594547/

This should be passing tests at least now, but there are still some
tests left to write. Most of what's in the patch is testing the new
authorization scope (e.g. system).

I'm currently taking advice on ways to extensively test six different
personas without duplication running rampant across test cases (project
admin, project member, project reader, system admin, system member,
system reader).

In summary, it does make the credential API much more self-service
oriented, which is something we should try and do everywhere (I picked
credentials first because it was already moved to flask).

> [1]
> https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/credential.py#n21
>
>> I sadly won't be at the PTG, but will be at the Berlin summit. Plus I
>> have a lot of Adjutant work planned for Stein, a large chunk of which is
>> refactors and reshuffling blueprints and writing up a roadmap, plus some
>> better entry point tasks for new contributors.
>>
>>> ### Standalone Keystone
>>>
>>> Also at the meeting and during office hours, we revived the discussion of what it would take to have a standalone keystone be a useful identity provider for non-OpenStack projects[12][13]. First up we'd need to turn keystone into a fully-fledged SAML IdP, which it's not at the moment (which is a point of confusion in our documentation), or even add support for it to act as an OpenID Connect IdP. This would be relatively easy to do (or at least not impossible). Then the application would have to use keystonemiddleware or its own middleware to route requests to keystone to issue and validate tokens (this is one aspect where we've previously discussed whether JWT could benefit us). Then the question is what should a not-OpenStack application do with keystone's "scoped RBAC"? It would all depend on how the resources of the application are grouped and whether they care about multitenancy in some form. Likely each application would have different needs and it would be difficult to find a one-size-fits-all approach. We're interested to know whether anyone has a burning use case for something like this.
>>>
>>> [12] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-192
>>> [13] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T17:01:30
>> This one is interesting because another department at Catalyst is
>> actually looking to use Keystone outside of the scope of OpenStack. They
>> are building a SaaS platform, and they need authn, authz (with some
>> basic RBAC), a service catalog (think API endpoint per software
>> offering), and most of those things are useful outside of OpenStack.
>> They can then use projects to signify a customer, and a project
>> (customer) could have one or more users accessing the management GUIs,
>> with roles giving them some RBAC. A large part of this is because they
>> can then also piggy back on a lot of work our team has done with
>> OpenStack and Keystone and even reuse some of our projects and tools for
>> billing and other things (Adjutant maybe?). They could use KeystoneAuth
>> for CLI and client tools, they can build their APIs using
>> Keystonemiddleware.
>>
>>
>> Then another reason why this actually interests the Catalyst Cloud team
>> is because we actually use Keystone with an SQL backend for our public
>> cloud, with the db in a multi-region galera cluster. Keystone is our
>> Idp, we don't federate it, and we now have a reasonably passable 2FA
>> option on it, with a better MFA option coming in Stein when I'm done
>> with Auth Receipts. We actually kind of like Keystone for our authn, and
>> because we didn't have any existing users when we first built our cloud
>> so using vanilla Keystone seemed like a sensible solution. We had plans
>> to migrate users and federate, or move to LDAP, but they never
>> materialized because maintaining more systems didn't make sense and did
>> add many useful benefits. Making Keystone a fully fledged Idp with SAML
>> and OpenID support would be fantastic because we could then build a tiny
>> single sign on around Keystone and use that for all our non-openstack
>> services.
>>
>> In fact I had a prototype side project planned which would be a tiny
>> Flask or Django app that would act as a single sign on for Keystone. It
>> would have a login form that handles the new MFA process with auth
>> receipts in Keystone, and on getting the token it would wrap that into
>> an OpenID token which other systems could interpret. With the
>> appropriate APIs for acting as a provider and most of those just doing
>> user actions with that token in Keystone. In theory I could have made it
>> a tiny entirely ephemeral app which only needs to know where keystone is
>> (no admin creds). Basically a tiny Idp around Keystone.
>>
>> But if Keystone goes down the path of supporting SAML and OpenID then
>> all we really need is a login GUI that supports auth receipts (and
>> plugin support for different types of MFA to match ones in Keystone),
>> which probably still should be a tiny side project rather than views in
>> Keystone (should Keystone really serve HTML?), or requiring Horizon
>> (Horizon could use it as a SSO). I would love to help with something
>> like this if we do go down that path. :)
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-------------- 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-dev/attachments/20180824/8da5feb0/attachment-0001.sig>