Open Stack

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.

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.