Open Stack

Excerpts from Sean Dague's message of 2017-03-15 08:45:54 -0400:
> On 03/13/2017 05:10 PM, Zane Bitter wrote:
> <snip>
> >> I'm not sure I agree. One can very simply inject needed credentials
> >> into a running VM and have it interact with the cloud APIs.
> > 
> > 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.
> 

Could we just let users manage a set of OAuth keys that have a subset
of their roles?