[Openstack-operators] [publiccloud-wg] [adjutant] Input on Adjutant's official project status

[Adrian Turjak]

Hello fellow public cloud providers (and others)!

Adjutant is in the process of being voted in (or not) as an official
project as part of OpenStack, but to help over the last few hurdles,
some input from the people who would likely benefit the most directly
from such a service existing would really be useful.

In the past you've probably talked to me about the need for some form of
business logic related APIs and services in OpenStack (signup, account
termination, project/user management, billing details management, etc).
In that space I've been trying to push Adjutant as a solution, not
because it's the perfect solution, but because we are trying to keep the
service as a cloud agnostic solution that could be tweaked for the
unique requirements of various clouds. It's also a place were we can
collaborate on these often rather miscellaneous business logic
requirements rather than us each writing our own entirely distinct thing
and wasting time and effort reinventing the wheel again and again.

The review in question where this discussion has been happening for a while:
https://review.openstack.org/#/c/553643/

And if you don't know much about Adjutant, here is a little background.

The current mission statement is:
"To provide an extensible API framework for exposing to users an
organization's automated business processes relating to account
management across OpenStack and external systems, that can be adapted to
the unique requirements of an organization's processes."

The docs: https://adjutant.readthedocs.io/en/latest/
The code: https://github.com/openstack/adjutant

And here is a rough feature list that was put together as part of the
review process for official project status:
https://etherpad.openstack.org/p/Adjutant_Features

If you have any questions about the service, don't hesitate to get in
touch, but some input on the current discussion would be very welcome!

Cheers,
Adrian Turjak





pEpkey.asc
Description: application/pgp-keys
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [all] How to handle python3 only projects

[Adrian Turjak]

Hello devs,

The python27 clock of doom ticks closer to zero
(https://pythonclock.org/) and officially dropping python27 support is
going to have to happen eventually, that though is a bigger topic.

Before we get there outright what we should think about is what place
python3 only projects have in OpenStack alongside ones that support both.

Given that python27's life is nearing the end, we should probably
support a project either transitioning to only python3 or new projects
that are only python3. Not to mention the potential inclusion of python3
only libraries in global-requirements.

Potentially we should even encourage python3 only projects, and
encourage deployers and distro providers to focus on python3 only (do
we?). Python3 only projects are now a reality, python3 only libraries
are now a reality, and most of OpenStack already supports python3. Major
libraries are dropping python27 support in newer versions, and we should
think about how we want to do it too.

So where do projects that want to stop supporting python27 fit in the
OpenStack ecosystem? Or given the impending end of python27, why should
new projects be required to support it at all, or should we heavily
encourage new projects to be python3 only (if not require it)?

It's not an easy topic, and there are likely lots of opinions on the
matter, but it's something to start considering.

Cheers!

- Adrian Turjak








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

[Openstack-operators] Anyone using Adjutant?

[Adrian Turjak]

Hello OpenStack Operators,

As the project lead for Adjutant I wanted to reach out and double check
how many clouds have deployed it and are potentially running it. I
believe the number is fairly small, and most of those I've probably been
in contact with, but wanted to also send this out in case anyone has
tried the service and is using it as well.

We're reaching out so we can hopefully work with you to preserve
backwards compatibility or a safe migration path as we move forward with
some large internal refactors. Until the service hits v1.0.0 we're
likely going to change quite a few things internally, but the API and
customer facing features shouldn't change much. Our hope is to work with
anyone deploying it to stay on top of our changes and make sure you're
not hit by the potentially breaking changes we need to make (policy
support, config rework, async task processing). We'll be tagging v0.4.0
soon and it should work as it does right now with no major changes to
the service or config at present. From there we'll start a more proper
change log and keep detailed notes about what deployers need to do as
they upgrade. The work we're doing will make certain elements of the
service much easier to deploy and configure, and add new features to,
but sadly requires us breaking some existing elements.

Catalyst Cloud is running it in production (fairly close to master most
of the time), so we will of course be careful that we avoid any breaking
changes from a customer facing perspective, and document what steps
we've needed to take during upgrades.

Please reach out if you are using it, and we'll make sure to keep you in
the loop as we potentially have to break things. :)

Cheers,
Adrian Turjak


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

Re: [Openstack-operators] custom dashboards

[Adrian Turjak]

We do a lot of custom dashboard stuff but adding additional dashboards
and panels into Horizon. While it's a bit weird at first, Horizon's
plugin mechanisms are reasonably flexible and good.


On 24/02/18 11:25, Paras pradhan wrote:
> What do you guys use to create custom dashboard for openstack? Do you
> use django and python openstack sdk  or modify the horizon dashboard?
>
>
> Thanks
> Paras.
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] [publiccloud-wg][keystone][Horizon] Multi-Factor Auth in OpenStack

[Adrian Turjak]

On 09/02/18 15:50, Lance Bragstad wrote:
> On 02/08/2018 03:36 PM, Adrian Turjak wrote:
>> My plan for the Rocky cycle is to work in Keystone and address the missing 
>> pieces I need to get MFA working properly throughout OpenStack in an 
>> actually useful way, and I'll provide updates for that once I have the specs 
>> ready to submit (am waiting until start of Rocky for that). The good thing, 
>> is that this current solution for MFA works, and it can be migrated from to 
>> the methods I intend to work on for Rocky. The same credential models will 
>> be used in Keystone, and I will write tools to take users with TOTP 
>> credentials and configure auth rules for them for more official MFA support 
>> in Keystone once it is useful.
> Are you planning to revive the previous proposal [0]? We should have
> stable/queens branch by EOW, so Rocky development will be here soon. Are
> you planning on attending the PTG? It might be valuable to discuss what
> you have and how we can integrate it upstream. I thought I remember the
> issue being policy related (where admins were required to update user
> secrets and it wasn't necessarily a self-serving API). Now that we're in
> a better place with system-scope, we might be able to move the ball
> forward a bit regarding your use case.
>
> [0] https://review.openstack.org/#/c/345705/
So the use case is not just self-management, that's a part of it, but
one at least we've solved outside of Keystone. The bigger issue is that
MFA as we currently have it in Keystone is... unfinished and very hard
to consume.

And no I won't be coming to the PTG. :(

The multi-auth-method approach is good, as are the per user auth rules,
but right now nothing is consuming it using more than one method. In
fact KeystoneAuth doesn't know how to deal with it. In part that is my
fault since I put my hand up to make KeystoneAuth work with Multi-method
auth, but... I gave up because it got ugly fast. We could make auth
methods in KeystoneAuth that are made up of multiple methods, but then
you need an explicit auth module for each combination... We need to
refactor that code to allow you to specify a combination and have the
code underneath do the right thing. The other issue is that you always
need to know ahead of time how to auth for a given user and their
specific auth rules, and you can't programmatically figure that out.

The missing piece is something that allows us to programmatically know
what is missing when 1 out of 2+ auth rules succeeds.

When a user with more than 1 auth rule attempts to auth to Keystone, if
they auth with 1 rule, but need 2 (password and totp), then the auth
will fail and the error will be unhelpful. Even if the error was
helpful, we can't rely on parsing error messages, that's unsafe. What
should happen is Keystone acknowledges they were successful with one of
their configured auth rules, at which point we know this user is
'probably' who they say they are. We now pass them a Partially Authed
Token, which says they've already authed with 'password', but are
missing 'totp' to complete their auth. The user can now return that
token, and the missing totp auth method, and get back a full token.

So the first spec I intend to propose is the Partially Authed Token
type. Which solves the challenge response problem we have, and lets us
actually know how to proceed when auth is unfinished. Once we have that,
we can update KeystoneAuth, then the CLI to support challenge response,
and then Horizon as well. Then we can look at user self management of MFA.

Amusingly the very original spec that brought it multi-auth methods into
Keystone talked about the need for a 'half-token':
https://adam.younglogic.com/2012/10/multifactor-auth-and-keystone/
https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn
https://review.openstack.org/#/c/21487/

But the 'half-token' was never implemented. :(


The MFA method in this original email was just... replace the password
auth method with one that expects an appended totp passcode. It's
simple, it doesn't break anything nor expect more than one auth method,
it works with Horizon and the CLI because of that, but it doesn't do
real challenge response. It's a stop gap measure for us since we're on
an older version of Keystone, and because the current methods are too
hard for our customers to actually consume. And most importantly, I can
migrate users from using it to using user auth rules, since Keystone
already stores the totp credential and all I need to then do is make
auth rules for users with a totp cred.


Hope that explains my plan, and why I'm going to be proposing it. It's
going to be a lot of work. :P




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

[Openstack-operators] [publiccloud-wg][keystone][Horizon] Multi-Factor Auth in OpenStack

[Adrian Turjak]

Hello fellow Public Cloud operators!

I'm quite sorry I haven't been able to attend the last few public cloud 
meetings, have been deep in various bits of work, and been very asleep when the 
meetings normally were.

That said, I have some interesting things some of you might like to play with:
https://github.com/catalyst-cloud/adjutant-mfa

The above is a collection of plugins for Keystone, Horizon, and Adjutant that 
help facilitate MFA on an OpenStack cloud. Note, that while this is a working 
solution, it isn't merged or part of anything official upstream, just using the 
various plugin mechanisms. It uses existing pieces of working logic, and does 
nothing that isn't able to be migrated from.

My plan for the Rocky cycle is to work in Keystone and address the missing 
pieces I need to get MFA working properly throughout OpenStack in an actually 
useful way, and I'll provide updates for that once I have the specs ready to 
submit (am waiting until start of Rocky for that). The good thing, is that this 
current solution for MFA works, and it can be migrated from to the methods I 
intend to work on for Rocky. The same credential models will be used in 
Keystone, and I will write tools to take users with TOTP credentials and 
configure auth rules for them for more official MFA support in Keystone once it 
is useful.

We will be deploying the above MFA solution in our cloud in the next Month, and 
I'll provide you some updates as to how that goes, but do play with it 
yourselves, and tell me what you think. The solution does require technical 
domain knowledge to setup, but the docs in the above repo should hopefully be 
straightforward, if not, get in touch and I can help.

I hope to have some other useful bits of 'missing public cloud features' 
updates for you soon too. 

Cheers,

Adrian Turjak



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

Re: [Openstack-operators] [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Adrian Turjak]

On 25/05/17 07:47, Lance Bragstad wrote:

> *Option 2*
>
> Implement global role assignments in keystone.
> /
> /
> /How it works:/
> /
> /
> Role assignments in keystone can be scoped to global context. Users
> can then ask for a globally scoped token 
>
> Pros:
> - This approach represents a more accurate long term vision for role
> assignments (at least how we understand it today)
> - Operators can create global roles and assign them as needed after
> the upgrade to give proper global scope to their users
> - It's easier to explain global scope using global role assignments
> instead of a special project
> - token.is_global = True and token.role = 'reader' is easier to
> understand than token.is_admin_project = True and token.role = 'reader'
> - A global token can't be associated to a project, making it harder
> for operations that require a project to consume a global token (i.e.
> I shouldn't be able to launch an instance with a globally scoped token)
>
> Cons:
> - We need to start from scratch implementing global scope in keystone,
> steps for this are detailed in the spec
>

>
> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad  > wrote:
>
> Hey all,
>
> To date we have two proposed solutions for tackling the admin-ness
> issue we have across the services. One builds on the existing
> scope concepts by scoping to an admin project [0]. The other
> introduces global role assignments [1] as a way to denote elevated
> privileges.
>
> I'd like to get some feedback from operators, as well as
> developers from other projects, on each approach. Since work is
> required in keystone, it would be good to get consensus before
> spec freeze (June 9th). If you have specific questions on either
> approach, feel free to ping me or drop by the weekly policy
> meeting [2].
>
> Thanks!
>

Please option 2. The concept of being an "admin" while you are only
scoped to a project is stupid when that admin role gives you super user
power yet you only have it when scoped to just that project. That
concept never really made sense. Global scope makes so much more sense
when that is the power the role gives.

At same time, it kind of would be nice to make scope actually matter. As
admin you have a role on Project X, yet you can now (while scoped to
this project) pretty much do anything anywhere! I think global roles is
a great step in the right direction, but beyond and after that we need
to seriously start looking at making scope itself matter, so that giving
someone 'admin' or some such on a project actually only gives them
something akin to project_admin or some sort of admin-lite powers scoped
to that project and sub-projects. That though falls into the policy work
being done, but should be noted, as it is related.

Still, at least global scope for roles make the superuser case make some
actual sense, because (and I can't speak for other deployers), we have
one project pretty much dedicated as an "admin_project" and it's just
odd to actually need to give our service users roles in a project when
that project is empty and a pointless construct for their purpose.

Also thanks for pushing this! I've been watching your global roles spec
review in hopes we'd go down that path. :)

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