Open Stack

On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
> > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
> > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
> > > > Can people help me work through the right set of tools for this use
> case
> > > > (has come up from several Operators) and map out a plan to implement
> it:
> > > >
> > > > Large cloud with many users coming from multiple Federation sources
> has
> > > > a policy of providing a minimal setup for each user upon first visit
> to
> > > > the cloud:  Create a project for the user with a minimal quota, and
> > > > provide them a role assignment.
> > > >
> > > > Here are the gaps, as I see it:
> > > >
> > > > 1.  Keystone provides a notification that a user has logged in, but
> > > > there is nothing capable of executing on this notification at the
> > > > moment.  Only Ceilometer listens to Keystone notifications.
> > > >
> > > > 2.  Keystone does not have a workflow engine, and should not be
> > > > auto-creating projects.  This is something that should be performed
> via
> > > > a Heat template, and Keystone does not know about Heat, nor should
> it.
> > > >
> > > > 3.  The Mapping code is pretty static; it assumes a user entry or a
> > > > group entry in identity when creating a role assignment, and neither
> > > > will exist.
> > > >
> > > > We can assume a special domain for Federated users to have per-user
> > > > projects.
> > > >
> > > > So; lets assume a Heat Template that does the following:
> > > >
> > > > 1. Creates a user in the per-user-projects domain
> > > > 2. Assigns a role to the Federated user in that project
> > > > 3. Sets the minimal quota for the user
> > > > 4. Somehow notifies the user that the project has been set up.
> > > >
> > > > This last probably assumes an email address from the Federated
> > > > assertion.  Otherwise, the user hits Horizon, gets a "not
> authenticated
> > > > for any projects" error, and is stumped.
> > > >
> > > > How is quota assignment done in the other projects now?  What happens
> > > > when a project is created in Keystone?  Does that information gets
> > > > transferred to the other services, and, if so, how?  Do most people
> use
> > > > a custom provisioning tool for this workflow?
> > > >
> > >
> > > I know at Dreamhost we built some custom integration that was triggered
> > > when someone turned on the Dreamcompute service in their account in our
> > > existing user management system. That integration created the account
> in
> > > keystone, set up a default network in neutron, etc. I've long thought
> we
> > > needed a "new tenant creation" service of some sort, that sits outside
> > > of our existing services and pokes them to do something when a new
> > > tenant is established. Using heat as the implementation makes sense,
> for
> > > things that heat can control, but we don't want keystone to depend on
> > > heat and we don't want to bake such a specialized feature into heat
> > > itself.
> > >
> >
> > I agree, an automation piece that is built-in and easy to add to
> > OpenStack would be great.
> >
> > I do not agree that it should be Heat. Heat is for managing stacks that
> > live on and change over time and thus need the complexity of the graph
> > model Heat presents.
> >
> > I'd actually say that Mistral or Ansible are better choices for this. A
> > service which listens to the notification bus and triggered a workflow
> > defined somewhere in either Ansible playbooks or Mistral's workflow
> > language would simply run through the "skel" workflow for each user.
> >
> > The actual workflow would probably almost always be somewhat site
> > specific, but it would make sense for Keystone to include a few basic
> ones
> > as "contrib" elements. For instance, the "notify the user" piece would
> > likely be simplest if you just let the workflow tool send an email. But
> > if your cloud has Zaqar, you may want to use that as well or instead.
> >
> > Adding Mistral here to see if they have some thoughts on how this
> > might work.
> >
> > BTW, if this does form into a new project, I suggest naming it
> > Skeleton[1]
>
> Following the pattern of Kite's naming, I think a Dirigible is a
> better way to get users into the cloud. :-)
>

lol +1

Is this use case specifically for keystone-to-keystone, or for federation
in general?

As an outcome of the Vancouver summit, we had a use case for mirroring a
federated user's project ID from the identity provider cloud to the service
provider cloud. The goal would be that a user can burst into a second cloud
and immediately receive a token scoped to the same project ID that they're
already familiar with (which implies a role assignment of some sort; for
example, member). That would have to be done in real time though, not by a
secondary service.

And with shadow users, we're looking at creating an identity (basically,
nothing but a user_id) in the second cloud anyway. And as another
consequence of shadow users, they wouldn't be getting a "federated token"
of any sort, but rather a simpler, local token, referencing a local
identity (the user_id that was just created automatically).

Adam, does any of this align with your use case?


>
> Doug
>
> >
> > [1] https://goo.gl/photos/EML6EPKeqRXioWfd8 (that was my front yard..)
> >
>
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151105/ef038f0a/attachment.html>