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? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev