Open Stack

On 17/07/17 23:12, 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?

My thought here was that if this were the case (i.e. persistent 
credentials are OK provided the user can lock down the privileges) then 
you could make a case that the current spec is on the right track. For 
now we implement the application credentials as non-persistent, people 
who know about it use at their own risk, and for people who don't 
there's no exposure. Later on we add the authorisation stuff and relax 
the non-persistence requirement.

On further reflection, I'm not convinced by this - if we care about 
protecting people who don't intentionally use/know about the feature 
now, then we should probably still care once the tools are in place for 
the people who are using it intentionally to lock it down tightly.

So I'm increasingly convinced that we need to do one of two things. Either:

* Agree with Colleen (elsewhere in the thread) that persistent 
application credentials are still better than the status quo and 
reinstate the project-scoped lifecycle in accordance with original 
intent of the spec; or

* Agree that the concerns raised by Morgan & Adam will always apply, and 
look for a solution that gives us automatic key rotation - which might 
be quite different in shape (I can elaborate if necessary).

(That said, I chatted about this briefly with Monty yesterday and he 
said that his recollection was that there is a long-term solution that 
will keep everyone happy. He'll try to remember what it is once he's 
finished on the version discovery stuff he's currently working on.)


I'm trying to avoid taking a side here because everyone is right. 
Currently anybody who want to do anything remotely 'cloudy' (i.e. have 
the application talk to OpenStack APIs) has to either share their 
personal password with the application (and by extension their whole 
team) or to do the thing that is the polar opposite of cloud: file a 
ticket with IT to get a service user account added <bangs head against 
desk> and share that password instead. And this really is a disaster for 
OpenStack. On the other hand, allowing the creation of persistent 
application credentials in the absence of regular automatic rotation 
does create risk for those folks who are not aggressively auditing them 
(perhaps because they have no legitimate use for them) and the result is 
likely to be lots of clouds disabling them by policy, keeping their 
users in the dark age of IT-ticket-filing <head...desk> and frustrating 
our interoperability goals.

It is possible in theory to satisfy both via the 'instance users' 
concept, but the Nova team's response to this has consistently been 
"prove to us that this has to be in Nova". Well, here's your answer.

cheers,
Zane.