Other OpenStack subsystems (such as Heat) handle this with Trusts. A service account is made in a different, usually SQL backed Keystone Domain and a trust is created associating the service account with the User.
This mostly works but does give the trusted account a lot of power, as the roles by default in OpenStack are pretty coarse grained. That should be solvable though. Thanks, Kevin ________________________________________ From: Clint Byrum [[email protected]] Sent: Wednesday, March 15, 2017 9:49 AM To: openstack-dev Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
