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.
__________________________________________________________________________
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
