Open Stack

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>