settingsLogin | Registersettings

[openstack-dev] [Keystone][PublicCloud] Introducing Adjutant, an OpenStack service for signups, user invites, password reset and more!

0 votes

Hello OpenStack Community,

I'd like to introduce to you all a service we have developed at Catalyst
and are now ready to release to the OpenStack community in hopes that
others may find it useful. As a public cloud provider we quickly ran
into a bunch of little issues around user management, sign-ups, and
other pieces of business logic that needed to fit into how we administer
the cloud but didn't entirely make sense as additions to existing
services. There were also a lot of actions we wanted to delegate to our
customers but couldn't do without giving them too much power in
Keystone, or wanted those actions to send emails, or extend to external
non-OpenStack services.

Enter Adjutant. Adjutant (previously called StackTask) was built as a
service to allow us to create business workflows that can be exposed in
some fashion over an API. A way for us to build reusable snippets of
code that we can tie together, and a flexible and pluggable API layer we
can expose those on. We needed these to be able to talk to our external
systems, as well as our OpenStack services, and provide us some basic
steps and in some cases the ability to require approval before an action
completes. In many ways Adjutant also works as a layer around Keystone
for us to build business logic around certain things we'd like our
customers to be able to do in very limited ways.

The service itself is built on Django with Django-Rest-Framework and is
an API service with the gui component built as a ui plugin for Horizon
that allows easy integration into an OpenStack dashboard.

Adjutant, as the name implies, is a helper, not a major service, but one
that smooths some situations and an easy place to offload some admin
tasks that a customer or non-admin should be able to trigger in a more
limited way. Not only that, but it stores the history of all these
tasks, who asked for them, and when they were completed. Anything a user
does through Adjutant is stored and able to be audited, with in future
the ability for project admins to be able to audit their own tasks and
see who of their users did something.

Out of the box it provides the following functionality:

  • User invitation by users with the 'projectadmin' or 'projectmod' role.
    o This will send out an email to the person you've invited with a
    submission token and let them setup their password and then
    grants them roles on your project. If their user exists already,
    will only require confirmation and then grant roles.
  • As a 'projectadmin' or 'projectmod' you can list the users with
    roles on your project and edit their roles or revoke them from your
    project.
  • Let non-admin users request a password reset.
    o User will be emailed a token which will let them reset their
    password.
  • Basic signup
    o Let a user request a new project. Requires admin approval and
    will create a new project and user, granting default roles on
    the new project. Will reuse existing user if present, or send an
    email to the user to setup their password.
  • Let a user update their email address.
    o Will notify old email, and send a confirmation token to the new.

Features coming in the future (most either almost done, or in prototype
stages):

  • Forced password reset
    o users with 'projectadmin' or 'projectmod'**can force a
    password reset for a given user in their projects
    o cloud admins can force password resets for users on their cloud.
    o changes user password to a randomly generated value and sends
    user a password reset token to their email.
    o user must reset before they can log in again.
  • Quota management for your project
    o As a 'projectadmin' or 'projectmod' you can request a change
    in quota to a set of predefined sizes (as set in the Adjutant
    conf). Sizes allows you to increase multiple related quotas at
    the same time. You can move to adjacent sizes without approval a
    number of times in a configurable window (days), or an admin can
    approve your quota change as well.
  • Hierarchical Multi-Tenancy in a single domain environment
    o 'project_admin' to be able to create sub-projects off the
    current scoped project.
    o This uses HMT properly in Keystone but does not require an admin
    role and enforces a naming convention to ensure unique
    namespaces per sub-projects and somewhat avoids the project name
    uniqueness issues per domain. It's basically some wrapper logic
    for HMT in Keystone.
    o This also adds inherited role support to the already existing
    user invite and user role editing features.
    o some VERY basic sub-project quota (number of sub-projects
    allowed) via metadata stored on a project in Keystone, with
    quota calculations in Adjutant checking against number of
    sub-projects created in your WHOLE tree within given shifting
    window. This is mainly to stop sub-projects as a means of
    getting around quota limits, and allows admins to approve
    sub-projects if beyond what a customer is allowed normally.
  • Account termination/resource termination
    o Be able to delete/disable a project and all the resources in it
    in one go, with some reporting, validation, and confirmation.
  • A way to setup and manage MFA credentials for a user
    o relies on work in Keystone around MFA, and serves only as a
    means to allow an initial challenge response that requires an
    initial passcode before MFA would become active for the user in
    Keystone.
    o and a similar process for deactivating MFA by needing a passcode.
    o with an adjutant-ui panel that displays an SVG QR code.
  • Support for User stores beyond Keystone
    o Allow Adjutant to create/manage users in LDAP/AD as part of
    normal user workflows.
    o This feature was always planned since Keystone does not support
    creation/editing when users come from LDAP, so the existing user
    store module is mostly an abstraction layer that can be made
    pluggable.

Adjutant also supports a simple enough plugin system that lets you
override existing actions and taskviews or build on top of them for your
own deployments or company specific circumstances. This lets you use the
core benefits of the service while keeping your company specific code in
a separate codebase that is easy to integrate.

The repos will soon be on the OpenStack gerrit, with launchpad for
bug/blueprints, but for now can be found here:
https://github.com/catalyst/adjutant
https://github.com/catalyst/adjutant-ui
https://github.com/catalyst/python-adjutantclient

The python client and cli are also on pypi:
https://pypi.python.org/pypi/python-adjutantclient

And there are existing tempest tests that need to be greatly expanded
(and also renamed):
https://github.com/catalyst/stacktask-tempest

Here is also an example plugin based on how we've integrated this with
our ERP system:
https://github.com/catalyst/adjutant-odoo
And to help test the plugin and allow importing of test features
Adjutant itself is also on pypi so plugins can use it as a requirement
for testing:
https://pypi.python.org/pypi/python-adjutant

Going forward we're looking for other develops and deployers in the
OpenStack community that are either trying to solve issues that fit
within this service, or need something that this service solves. Let us
pool our resources and make something that can help others avoid the
same pitfalls and development work! There is a lot more we have planned
for the roadmap ranging from larger architectural improvements, useful
features, to minor but useful tweaks. It still has a bunch of growth and
maturity to achieve as a project, but we're running it in production (an
older state at least, with newer coming soon) and it will only get
better in time.

If this sounds interesting to you, get in touch, try it out, get involved!

Cheers,
Adrian Turjak


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 2, 2017 in openstack-dev by Adrian_Turjak (2,660 points)   4 7

1 Response

0 votes

We caught up with some of the Catalyst guys at the Melbourne OpenStack
Australia day and they gave us a demo of this. Looks like a really nice
project that I think might replace some of existing user management
workflow.

Allowing project managers to invite collaborators and self-manage their
permissions and to create nested projects (without requiring admin
intervention) would work well for us on the Nectar cloud.

Thanks for the contribution Adrian. Hoping we can find some time soon to
test this out and contribute.

cheers,
Andy

On 29 May 2017 at 17:01, Adrian Turjak adriant@catalyst.net.nz wrote:

Hello OpenStack Community,

I'd like to introduce to you all a service we have developed at Catalyst
and are now ready to release to the OpenStack community in hopes that
others may find it useful. As a public cloud provider we quickly ran into a
bunch of little issues around user management, sign-ups, and other pieces
of business logic that needed to fit into how we administer the cloud but
didn't entirely make sense as additions to existing services. There were
also a lot of actions we wanted to delegate to our customers but couldn't
do without giving them too much power in Keystone, or wanted those actions
to send emails, or extend to external non-OpenStack services.

Enter Adjutant. Adjutant (previously called StackTask) was built as a
service to allow us to create business workflows that can be exposed in
some fashion over an API. A way for us to build reusable snippets of code
that we can tie together, and a flexible and pluggable API layer we can
expose those on. We needed these to be able to talk to our external
systems, as well as our OpenStack services, and provide us some basic steps
and in some cases the ability to require approval before an action
completes. In many ways Adjutant also works as a layer around Keystone for
us to build business logic around certain things we'd like our customers to
be able to do in very limited ways.

The service itself is built on Django with Django-Rest-Framework and is an
API service with the gui component built as a ui plugin for Horizon that
allows easy integration into an OpenStack dashboard.

Adjutant, as the name implies, is a helper, not a major service, but one
that smooths some situations and an easy place to offload some admin tasks
that a customer or non-admin should be able to trigger in a more limited
way. Not only that, but it stores the history of all these tasks, who asked
for them, and when they were completed. Anything a user does through
Adjutant is stored and able to be audited, with in future the ability for
project admins to be able to audit their own tasks and see who of their
users did something.

Out of the box it provides the following functionality:

  • User invitation by users with the 'projectadmin' or 'projectmod'
    role.

    • This will send out an email to the person you've invited with a
      submission token and let them setup their password and then grants them
      roles on your project. If their user exists already, will only require
      confirmation and then grant roles.
  • As a 'projectadmin' or 'projectmod' you can list the users with
    roles on your project and edit their roles or revoke them from your project.
  • Let non-admin users request a password reset.

    • User will be emailed a token which will let them reset their
      password.
  • Basic signup

    • Let a user request a new project. Requires admin approval and
      will create a new project and user, granting default roles on the new
      project. Will reuse existing user if present, or send an email to the user
      to setup their password.
  • Let a user update their email address.

    • Will notify old email, and send a confirmation token to the new.

Features coming in the future (most either almost done, or in prototype
stages):

  • Forced password reset
  • users with 'projectadmin' or 'projectmod' can force a password
    reset for a given user in their projects

    • cloud admins can force password resets for users on their cloud.
    • changes user password to a randomly generated value and sends
      user a password reset token to their email.
    • user must reset before they can log in again.
  • Quota management for your project

    • As a 'projectadmin' or 'projectmod' you can request a change in
      quota to a set of predefined sizes (as set in the Adjutant conf). Sizes
      allows you to increase multiple related quotas at the same time. You can
      move to adjacent sizes without approval a number of times in a configurable
      window (days), or an admin can approve your quota change as well.
  • Hierarchical Multi-Tenancy in a single domain environment

    • 'project_admin' to be able to create sub-projects off the current
      scoped project.
    • This uses HMT properly in Keystone but does not require an admin
      role and enforces a naming convention to ensure unique namespaces per
      sub-projects and somewhat avoids the project name uniqueness issues per
      domain. It's basically some wrapper logic for HMT in Keystone.
    • This also adds inherited role support to the already existing
      user invite and user role editing features.
    • some VERY basic sub-project quota (number of sub-projects
      allowed) via metadata stored on a project in Keystone, with quota
      calculations in Adjutant checking against number of sub-projects created in
      your WHOLE tree within given shifting window. This is mainly to stop
      sub-projects as a means of getting around quota limits, and allows admins
      to approve sub-projects if beyond what a customer is allowed normally.
    • Account termination/resource termination
    • Be able to delete/disable a project and all the resources in it
      in one go, with some reporting, validation, and confirmation.
    • A way to setup and manage MFA credentials for a user
    • relies on work in Keystone around MFA, and serves only as a means
      to allow an initial challenge response that requires an initial passcode
      before MFA would become active for the user in Keystone.
    • and a similar process for deactivating MFA by needing a passcode.
    • with an adjutant-ui panel that displays an SVG QR code.
  • Support for User stores beyond Keystone

    • Allow Adjutant to create/manage users in LDAP/AD as part of
      normal user workflows.
    • This feature was always planned since Keystone does not support
      creation/editing when users come from LDAP, so the existing user store
      module is mostly an abstraction layer that can be made pluggable.

Adjutant also supports a simple enough plugin system that lets you
override existing actions and taskviews or build on top of them for your
own deployments or company specific circumstances. This lets you use the
core benefits of the service while keeping your company specific code in a
separate codebase that is easy to integrate.

The repos will soon be on the OpenStack gerrit, with launchpad for
bug/blueprints, but for now can be found here:
https://github.com/catalyst/adjutant
https://github.com/catalyst/adjutant-ui
https://github.com/catalyst/python-adjutantclient

The python client and cli are also on pypi:
https://pypi.python.org/pypi/python-adjutantclient
https://pypi.python.org/pypi/python-stacktaskclient

And there are existing tempest tests that need to be greatly expanded (and
also renamed):
https://github.com/catalyst/stacktask-tempest

Here is also an example plugin based on how we've integrated this with our
ERP system:
https://github.com/catalyst/adjutant-odoo
And to help test the plugin and allow importing of test features Adjutant
itself is also on pypi so plugins can use it as a requirement for testing:
https://pypi.python.org/pypi/python-adjutant

Going forward we're looking for other develops and deployers in the
OpenStack community that are either trying to solve issues that fit within
this service, or need something that this service solves. Let us pool our
resources and make something that can help others avoid the same pitfalls
and development work! There is a lot more we have planned for the roadmap
ranging from larger architectural improvements, useful features, to minor
but useful tweaks. It still has a bunch of growth and maturity to achieve
as a project, but we're running it in production (an older state at least,
with newer coming soon) and it will only get better in time.

If this sounds interesting to you, get in touch, try it out, get involved!

Cheers,
Adrian Turjak


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 2, 2017 by Andy_Botting (380 points)  
...