On 07/19/2017 09:27 PM, Monty Taylor wrote: > On 07/19/2017 12:18 AM, Zane Bitter wrote: >> On 18/07/17 10:55, Lance Bragstad wrote: >>>> >>>> Would Keystone folks be happy to allow persistent credentials once >>>> we have a way to hand out only the minimum required privileges? >>>> >>>> >>>> If I'm understanding correctly, this would make application >>>> credentials dependent on several cycles of policy work. Right? >>> >>> I think having the ability to communicate deprecations though >>> oslo.policy would help here. We could use it to move towards better >>> default roles, which requires being able to set minimum privileges. >>> >>> Using the current workflow requires operators to define the minimum >>> privileges for whatever is using the application credential, and >>> work that into their policy. Is that the intended workflow that we >>> want to put on the users and operators of application credentials? >> >> The plan is to add an authorisation mechanism that is user-controlled >> and independent of the (operator-controlled) policy. The beginnings >> of this were included in earlier drafts of the spec, but were removed >> in patch set 19 in favour of leaving them for a future spec: >> >> https://review.openstack.org/#/c/450415/18..19/specs/keystone/pike/application-credentials.rst > > > Yes - that's right - and I expect to start work on that again as soon > as this next keystoneauth release with version discovery is out the door. > > It turns out there are different POVs on this topic, and it's VERY > important to be clear which one we're talking about at any given point > in time. A bunch of the confusion just in getting as far as we've > gotten so far came from folks saying words like "policy" or "trusts" > or "ACLs" or "RBAC" - but not clarifying which group of cloud users > they were discussing and from what context. > > The problem that Zane and I are are discussing and advocating for are > for UNPRIVILEDGED users who neither deploy nor operate the cloud but > who use the cloud to run applications. > > Unfortunately, neither the current policy system nor trusts are useful > in any way shape or form for those humans. Policy and trusts are tools > for cloud operators to take a certain set of actions. > > Similarly, the concern from the folks who are not in favor of > project-lifecycled application credentials is the one that Zane > outlined - that there will be $someone with access to those > credentials after a User change event, and thus $security will be > compromised. > > There is a balance that can and must be found. The use case Zane and I > are talking about is ESSENTIAL, and literally ever single human who is > a actually using OpenStack to run applications needs it. Needed it > last year in fact, and they are, in fact doing things like writing > ssh-agent like daemons in which they can store their corporate LDAP > credentials so that their automation will work because we're not > giving them a workable option. > > That said, the concerns about not letting a thing out the door that is > insecure by design like PHP4's globally scoped URL variables is also > super important. > > So we need to find a design that meets both goals. > > I have thoughts on the topic, but have been holding off until > version-discovery is out the door. My hunch is that, like application > credentials, we're not going to make significant headway without > getting humans in the room - because the topic is WAY too fraught with > peril. > > I propose we set aside time at the PTG to dig in to this. Between Zane > and I and the Keystone core team I have confidence we can find a way out.
Done. I've added this thread to keystone's planning etherpad under cross-project things we need to talk about [0]. Feel free to elaborate and fill in context as you see fit. I'll make sure the content makes it's way into a dedicated etherpad before we have that discussion (usually as I go through each topic and plan the schedule). [0] https://etherpad.openstack.org/p/keystone-queens-ptg > > Monty > > PS. It will not help to solve limited-scope before we solve this. > Limited scope is an end-user opt-in action and having it does not > remove the concerns that have been expressed. > > __________________________________________________________________________ > > 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
