[openstack-dev] [tc][appcat] The future of the App Catalog

Kristi Nikolla kristi at nikolla.me
Wed Mar 15 16:35:45 UTC 2017


This might be related to the current discussion. 

In one of the keystone PTG sessions we started to talk about API keys. [0]
A spec is being written and discussed. [1]

This would allow the user to provision API key credentials with a subset of roles for use inside of their applications. Removing the need to inject the actual user credentials inside an application.

[0] http://lbragstad.com/keystone-pike-ptg-summary/
[1] https://review.openstack.org/#/c/438761


> On Mar 15, 2017, at 8:45 AM, Sean Dague <sean at dague.net> wrote:
> 
> On 03/13/2017 05:10 PM, Zane Bitter wrote:
>> 
>> Demo please!
>> 
>> Most Keystone backends are read-only, you can't even create a new user
>> account yourself. It's an admin-only API anyway. The only non-expiring
>> credential you even *have*, ignoring the difficulties of getting it to
>> the server, is your LDAP password. Would *you* put *your* LDAP password
>> on an internet-facing server? I would not.
> 
> So is one of the issues to support cloud native flows that our user auth
> system, which often needs to connect into traditional enterprise
> systems, doesn't really consider that?
> 
> I definitely agree, if your cloud is using your LDAP password, which
> gets you into your health insurance and direct deposit systems at your
> employeer, sticking this into a cloud server is a no go.
> 
> Thinking aloud, I wonder if user provisionable sub users would help
> here. They would have all the same rights as the main user (except
> modify other subusers), but would have a dedicated user provisioned
> password. You basically can carve off the same thing from Google when
> you have services that can't do the entire oauth/2factor path. Fastmail
> rolled out something similar recently as well.
> 
> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> 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




More information about the OpenStack-dev mailing list