On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak <[email protected]> wrote: <snip> > > > 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>" > > On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak <[email protected]> wrote: > > > On 16/05/17 14:00, Adrian Turjak wrote: > <snip>
> 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. > It's not just expiry. I think your proposal is missing one of the major use cases: empowerment of non-admin users. A non-admin can't create new users themselves, they have to (as you've pointed out) ask an admin to do it for them. As an application developer, I want to be able to delegate a subset of my own roles to a programmatic entity without being dependent on some other human. One of the (numerous) specs proposed seeks to address that use case: https://review.openstack.org/#/c/396634 Colleen
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
