[openstack-dev] [tc][appcat] The future of the App Catalog
Fox, Kevin M
Kevin.Fox at pnnl.gov
Wed Mar 15 17:21:38 UTC 2017
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.
From: Clint Byrum [clint at fewbar.com]
Sent: Wednesday, March 15, 2017 9:49 AM
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:
> >> 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-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev