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