Open Stack

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.

	-Sean

-- 
Sean Dague
http://dague.net