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:


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.


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

Reply via email to