Open Stack

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak <adriant at catalyst.net.nz>
wrote:

>
> On 16/05/17 01:09, Lance Bragstad wrote:
>
>
>
> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mordred at inaugust.com>
> wrote:
>
>> On 05/11/2017 02:32 PM, Lance Bragstad wrote:
>>
>>> Hey all,
>>>
>>> One of the Baremetal/VM sessions at the summit focused on what we need
>>> to do to make OpenStack more consumable for application developers [0].
>>> As a group we recognized the need for application specific passwords or
>>> API keys and nearly everyone (above 85% is my best guess) in the session
>>> thought it was an important thing to pursue. The API
>>> key/application-specific password specification is up for review [1].
>>>
>>> The problem is that with all the recent churn in the keystone project,
>>> we don't really have the capacity to commit to this for the cycle. As a
>>> project, we're still working through what we've committed to for Pike
>>> before the OSIC fallout. It was suggested that we reach out to the PWG
>>> to see if this is something we can get some help on from a keystone
>>> development perspective. Let's use this thread to see if there is anyway
>>> we can better enable the community through API keys/application-specific
>>> passwords by seeing if anyone can contribute resources to this effort.
>>>
>>
>> In the session, I signed up to help get the spec across the finish line.
>> I'm also going to do my best to write up something resembling a user story
>> so that we're all on the same page about what this is, what it isn't and
>> what comes next.
>>
>
> Thanks Monty. If you have questions about the current proposal, Ron might
> be lingering in IRC (rderose). David (dstanek) was also documenting his
> perspective in another spec [0].
>
>
> [0] https://review.openstack.org/#/c/440593/
>
>
>
> Based on the specs that are currently up in Keystone-specs, I would highly
> recommend not doing this per user.
>
> The scenario I imagine is you have a sysadmin at a company who created a
> ton of these for various jobs and then leaves. The company then needs to
> keep his user account around, or create tons of new API keys, and then
> disable his user once all the scripts he had keys for are replaced. Or more
> often then not, disable his user and then cry as everything breaks and no
> one really knows why or no one fully documented it all, or didn't read the
> docs. Keeping them per project and unrelated to the user makes more sense,
> as then someone else on your team can regenerate the secrets for the
> specific Keys as they want. Sure we can advise them to use generic user
> accounts within which to create these API keys but that implies password
> sharing which is bad.
>
>
> That said, I'm curious why we would make these as a thing separate to
> users. In reality, if you can create users, you can create API specific
> users. Would this be a different authentication mechanism? Why? Why not
> just continue the work on better access control and let people create users
> for this. Because lets be honest, isn't a user already an API key? The
> issue (and the Ron's spec mentions this) is a user having too much access,
> how would this fix that when the issue is that we don't have fine grained
> policy in the first place? How does a new auth mechanism fix that? Both
> specs mention roles so I assume it really doesn't. If we had fine grained
> policy we could just create users specific to a service with only the roles
> it needs, and the same problem is solved without any special API, new auth,
> or different 'user-lite' object model. It feels like this is trying to
> solve an issue that is better solved by fixing the existing problems.
>
> I like the idea behind these specs, but... I'm curious what exactly they
> are trying to solve. Not to mention if you wanted to automate anything
> larger such as creating sub-projects and setting up a basic network for
> each new developer to get access to your team, this wouldn't work unless
> you could have your API key inherit to subprojects or something more
> complex, at which point they may as well be users. Users already work for
> all of this, why reinvent the wheel when really the issue isn't the wheel
> itself, but the steering mechanism (access control/policy in this case)?
>
>
All valid points, but IMO the discussions around API keys didn't set out to
fix deep-rooted issues with policy. We have several specs in flights across
projects to help mitigate the real issues with policy [0] [1] [2] [3] [4].

I see an API key implementation as something that provides a cleaner fit
and finish once we've addressed the policy bits. It's also a familiar
concept for application developers, which was the use case the session was
targeting.

I probably should have laid out the related policy work before jumping into
API keys. We've already committed a bunch of keystone resource to policy
improvements this cycle, but I'm hoping we can work API keys and policy
improvements in parallel.

[0] https://review.openstack.org/#/c/460344/
[1] https://review.openstack.org/#/c/462733/
[2] https://review.openstack.org/#/c/464763/
[3] https://review.openstack.org/#/c/433037/
[4] https://review.openstack.org/#/c/427872/


>
> Tangentially related to this (because my reasons are different), on our
> cloud I'm actually working on something like this, but under the hood all
> I'm doing is creating a user with a generated password and enforcing a
> username convention. I ask them for a name and what roles they want for the
> user and I spit out:
> username: "service_user_for_web_app_1@<project_id>"
> password: "<some_generated_password>"
>
> l'lI always generate/regenerate that password for them, and once shown to
> them once, they can't ever see it again since the plaintext secret is never
> stored. Sure I can't stop them from logging into the dashboard with that
> user or changing the password themselves directly, but that's impossible to
> avoid without being able to set a fine grained role that this user can't
> access password changing stuff. Ultimately though the user changing their
> password isn't a problem, and someone else can always delete the user or
> regen a password.
>
> The only reason I'm even working on this is because we currently only
> allow emails as username on our cloud through our management service. We
> did that to avoid unique name constraints in a single domain, and to allow
> us easier ways to do password reset tokens and inviting others to join your
> project and set their own user password. But... our customers also need a
> way to create service users with set roles. By enforcing the name@<project_id>
> convention I get around the username unique constraint but let them give
> useful descriptive names to these users.
>
> Also worth noting that we have some custom policy files to allow some very
> limited fine grained access control with roles. All I really want/need is
> better/dynamic policies and honestly users are all the API keys I can ever
> see being needed.
>
> __________________________________________________________________________
> 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/20170515/bb2b1dee/attachment.html>