[openstack-dev] [keystone][nova] Persistent application credentials
mordred at inaugust.com
Thu Jul 20 02:27:40 UTC 2017
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
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
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.
More information about the OpenStack-dev