[openstack-dev] [all][keystone][product] api keys/application specific passwords

Adrian Turjak adriant at catalyst.net.nz
Tue May 16 02:10:13 UTC 2017

On 16/05/17 14:00, Adrian Turjak wrote:
> On 16/05/17 13:29, Lance Bragstad wrote:
>> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
>> <adriant at catalyst.net.nz <mailto: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 <mailto: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/
>>>     <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/
> I'm well aware of the policy work, and it is fantastic to see it
> progressing! I can't wait to actually be able to play with that stuff!
> We've been painstakingly tweaking the json policy files which is a
> giant mess.
> I'm just concerned that this feels like a feature we don't really need
> when really it's just a slight variant of a user with a new auth model
> (that is really just another flavour of username/password). The sole
> reason most of the other cloud services have API keys is because a
> user can't talk to the API directly. OpenStack does not have that
> problem, users are API keys. So I think what we really need to
> consider is what exact benefit does API keys actually give us that
> won't be solved with users and better policy?
> From my look at the specs the only feature difference compared to
> users is optional expiry of the API keys. Why make something entirely
> different for just that one feature when, as David says in his spec,
> there is debate if that feature is even a good idea.
> As an application developer, I don't see why I can't just create a
> user and limit the roles. I feel as if this is better addressed with
> documentation because it almost sounds like people are asking for
> something that already exists, but just doesn't have as nice an API as
> they would like. Another option, make a better API in Keystone for
> user creation/management alongside the old one? That's pretty much
> what we did, except we wrote a service to act as a proxy/wrapper
> around Keystone for some customer actions.

If expiry is the killer feature, why no just add it to users? Temporary
user accounts could solve that, and probably be useful beyond the scope
of just API keys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/b4a34c50/attachment.html>

More information about the OpenStack-dev mailing list