On 05/16/2017 05:39 AM, Sean Dague wrote:
On 05/15/2017 10:00 PM, Adrian Turjak wrote:
On 16/05/17 13:29, Lance Bragstad wrote:
On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
<adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote:
<snip>
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.
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? 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)?
All valid points, but IMO the discussions around API keys didn't set
out to fix deep-rooted issues with policy. We have several specs in
flights across projects to help mitigate the real issues with policy
[0] [1] [2] [3] [4].
I see an API key implementation as something that provides a cleaner
fit and finish once we've addressed the policy bits. It's also a
familiar concept for application developers, which was the use case
the session was targeting.
I probably should have laid out the related policy work before jumping
into API keys. We've already committed a bunch of keystone resource to
policy improvements this cycle, but I'm hoping we can work API keys
and policy improvements in parallel.
[0] https://review.openstack.org/#/c/460344/
[1] https://review.openstack.org/#/c/462733/
[2] https://review.openstack.org/#/c/464763/
[3] https://review.openstack.org/#/c/433037/
[4] https://review.openstack.org/#/c/427872/
I'm well aware of the policy work, and it is fantastic to see it
progressing! I can't wait to actually be able to play with that stuff!
We've been painstakingly tweaking the json policy files which is a giant
mess.
I'm just concerned that this feels like a feature we don't really need
when really it's just a slight variant of a user with a new auth model
(that is really just another flavour of username/password). The sole
reason most of the other cloud services have API keys is because a user
can't talk to the API directly. OpenStack does not have that problem,
users are API keys. So I think what we really need to consider is what
exact benefit does API keys actually give us that won't be solved with
users and better policy?
The benefits of API key are if it's the same across all deployments, so
your applications can depend on it working. That means the application
has to be able to:
1. provision an API Key with normal user credentials
2. set/reduce permissions with that with those same user credentials
3. operate with those credentials at the project level (so that when you
leave, someone else in your dept can take over)
4. have all it's resources built in the same project that you are in, so
API Key created resources could interact with manually created resources.
5. revoke at any time (and possibly bake in an expiration to begin with)
#1 means these can't just be users. By the user survey 30% are using
LDAP/AD, which means the authority to create a user isn't even cloud
admin level, it's company AD level. It may literally be impossible to do.
#2 means permissions can't be done with roles. Normal users can't create
roles, and roles don't properly express permissions inherent in them
either. Even if users started to be able to create roles, that would
mean an incredible role explosion.
#2 also means this interface can't use policy. Policy an internal
structure for operators setting allow points, and is a DSL that we
*really* don't want to make everyone learn every bit of.
#4 means this can't be done with special projects where users could
create other users using the existing SQL split backend setup in
keystone (even if they had AD). This is complicated to setup in the
first place, but if API Key created servers aren't able to get to the
network that was manually setup in a different tenant, the usefulness is
limited.
This is why the proposal out of the room going forward was some concrete
steps:
1) Make a new top level construct of an APPKey that exists within a
project, that all users can create in projects they are members of.
This immediately solves #1. And even inheriting Member role becomes
useful because of the revoke facility. There are now a set of
credentials that are ephemeral enough to back into images / scripts,
that aren't also getting into your health records or direct deposit at
your company.
2) Provide a mechanism to reduce what these APPKeys can do. Policy &
Roles is actually the wrong approach, those are operator constructs. API
consuming things understand operations in terms of ("Region1",
"compute", "/servers", "GET"). Something along those lines would be
provided as the way to describe permissions from a user.
The complaint is this is a second way of describing permissions. It is.
But the alternative to teach our entire user base about policy name
points is ... far less appealing. We should be tailoring this to the
audience we want to consume it.
Yes, these are 2 distinct steps, but I think it's disengenous to say the
first step is pointless until the second one is done. The first step
immediately enables a set of use cases that are completely blocked today.
Yes to all of what Sean said- thank you, that summarizes the issue quite
well.
I was originally of the same POV - "screw this, we already have a
mechanism for creating users, let's just use it" - but a "user" has a
bunch of specific connotations which we get entangled with and thus
remain perpetually unable to make progress on this.
A "User" creating an "API Key" is that user authorizing an 'application'
to use the API as them. (there is a sticky use case we need to figure
out in the spec that relates to user lifecycle in shared projects)
FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll
with that until someone has a better idea. I'm uncrazy about it for two
reasons:
a) the word "key" implies things to people that may or may not be true
here. If we do stick with it - we need some REALLY crisp language about
what it is and what it isn't.
b) Rackspace Public Cloud (and back in the day HP Public Cloud) have a
thing called by this name. While what's written in the spec is quite
similar in usage to that construct, I'm wary of re-using the name
without the semantics actually being fully the same for risk of user
confusion. "This uses api-key... which one?" Sean's email uses "APPKey"
instead of "APIKey" - which may be a better term. Maybe just
"ApplicationAuthorization"?
Anyway - I will say that this is an area where the discussion at the
Forum was very helpful in expanding my understanding and changing my
opinion - to the point where I'm now happy helping drive the spec. Score
one for the Forum!
__________________________________________________________________________
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
