<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak <span dir="ltr"><<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:</div><div class="gmail_quote"><snip><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    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:<br>
    username: "service_user_for_web_app_1@<<wbr>project_id>"<br>
    password: "<some_generated_password>"<br>
    <br></div></blockquote><div> </div>On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak <span dir="ltr"><<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-h5"><br><div class="gmail-m_-2800704788950076425moz-cite-prefix">On 16/05/17 14:00, Adrian Turjak wrote:</div></div></div></div></blockquote><div><snip> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-h5"><blockquote type="cite">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?<br><br>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.<br><br>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.<br></blockquote></div></div>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.<br></div></blockquote><div> </div><div>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: <a href="https://review.openstack.org/#/c/396634">https://review.openstack.org/#/c/396634</a></div><div><br></div><div>Colleen</div></div></div></div>