On 15/05/17 20:07, Adrian Turjak wrote:
On 16/05/17 01:09, Lance Bragstad wrote:
On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mord...@inaugust.com
<mailto:mord...@inaugust.com>> wrote:
On 05/11/2017 02:32 PM, Lance Bragstad wrote:
Hey all,
One of the Baremetal/VM sessions at the summit focused on what
we need
to do to make OpenStack more consumable for application
developers [0].
As a group we recognized the need for application specific
passwords or
API keys and nearly everyone (above 85% is my best guess) in
the session
thought it was an important thing to pursue. The API
key/application-specific password specification is up for
review [1].
The problem is that with all the recent churn in the keystone
project,
we don't really have the capacity to commit to this for the
cycle. As a
project, we're still working through what we've committed to
for Pike
before the OSIC fallout. It was suggested that we reach out to
the PWG
to see if this is something we can get some help on from a
keystone
development perspective. Let's use this thread to see if there
is anyway
we can better enable the community through API
keys/application-specific
passwords by seeing if anyone can contribute resources to this
effort.
In the session, I signed up to help get the spec across the finish
line. I'm also going to do my best to write up something
resembling a user story so that we're all on the same page about
what this is, what it isn't and what comes next.
Thanks Monty. If you have questions about the current proposal, Ron
might be lingering in IRC (rderose). David (dstanek) was also
documenting his perspective in another spec [0].
[0] https://review.openstack.org/#/c/440593/
Based on the specs that are currently up in Keystone-specs, I would
highly recommend not doing this per user.
The scenario I imagine is you have a sysadmin at a company who created a
ton of these for various jobs and then leaves. The company then needs to
keep his user account around, or create tons of new API keys, and then
disable his user once all the scripts he had keys for are replaced. Or
more often then not, disable his user and then cry as everything breaks
and no one really knows why or no one fully documented it all, or didn't
read the docs. Keeping them per project and unrelated to the user makes
more sense, as then someone else on your team can regenerate the secrets
for the specific Keys as they want. Sure we can advise them to use
generic user accounts within which to create these API keys but that
implies password sharing which is bad.
Yes, absolutely. Like other OpenStack resources, API keys need to belong
to the project, not the user.
That said, I'm curious why we would make these as a thing separate to
users. In reality, if you can create users, you can create API specific
users. Would this be a different authentication mechanism? Why? Why not
just continue the work on better access control and let people create
users for this. Because lets be honest, isn't a user already an API key?
Essentially, with the exception that an API key only gets you
authenticated to OpenStack, whereas a user's 'key' (password) probably
also gets them into a lot of other things.
I want to be clear though: if that's the only benefit we get from API
keys then we are *failing*. We must put fine-grained authorisation
control in the end user's hands to actually solve the problem.
The issue (and the Ron's spec mentions this) is a user having too much
access, how would this fix that when the issue is that we don't have
fine grained policy in the first place? How does a new auth mechanism
fix that? Both specs mention roles so I assume it really doesn't. If we
had fine grained policy we could just create users specific to a service
with only the roles it needs, and the same problem is solved without any
special API, new auth, or different 'user-lite' object model. It feels
like this is trying to solve an issue that is better solved by fixing
the existing problems.
I like the idea behind these specs, but... I'm curious what exactly they
are trying to solve. Not to mention if you wanted to automate anything
larger such as creating sub-projects and setting up a basic network for
each new developer to get access to your team, this wouldn't work unless
you could have your API key inherit to subprojects or something more
complex, at which point they may as well be users. Users already work
for all of this, why reinvent the wheel when really the issue isn't the
wheel itself, but the steering mechanism (access control/policy in this
case)?
This was my assumption to start with as well - create a separate domain
backed by a DB, allow all users (not just admins) to create 'user'
accounts in that domain and assign roles on the current project that
they themselves hold to those accounts. That combined with a sane
default policy (where not every role gives you total access to the
projects) gets you to a point where you have application accounts
associated with a project but with no permissions to do anything. From
there you can add in a standard way of allowing the (actual) user to
delegate additional permissions to the account that are not captured in
policy.
Note that *either* way you end up with two authorisation mechanisms:
policy.json for operators and something else that end users can control.
Both mechanisms _could_ rely on Keystone roles[1], but likely at the
cost of an explosion of proliferating roles.
TBH I don't care too much which way we do it as long as it gets done :)
One point that was made in the session was that various organisations
may have strict policies or compliance requirements around how 'users'
are authenticated, and that we can pre-emptively avoid a world of hurt
for some of them by creating a primitive that is named literally
anything but 'user'.
A User-based system could possibly get operator-deployed applications
(i.e. Trove/Sahara/Magnum) to where they'd need to be quicker - which is
a consideration because this is a blocker for Kuryr - but I think they'd
end up in the same place. (I'd be more confident if we had the
service-locked VMs feature in Nova.)
The bottom line seems to be that it's a trade-off between having
different authorisation primitives for operators and users, or an
explosion of Keystone roles.
cheers,
Zane.
[1] Adam's talk
https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control
offered one such mechanism. Everybody in this thread should probably
watch that.
__________________________________________________________________________
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
