[openstack-dev] [all][keystone][product] api keys/application specific passwords

Sean Dague sean at dague.net
Wed May 17 11:20:44 UTC 2017

On 05/16/2017 07:34 PM, Adrian Turjak wrote:
> Anyway that aside, I'm sold on API keys as a concept in this case
> provided they are project owned rather than user owned, I just don't
> think we should make them too unique, and we shouldn't be giving them a
> unique policy system because that way madness lies.
> Policy is already a complicated system, lets not have to maintain two
> systems. Any policy system we make for API keys ought to be built on top
> of the policy systems we end up with using roles. An explosion of roles
> will happen with dynamic policy anyway, and yes sadly it will be a DSL
> for some clouds, but no sensible cloud operator is going to allow a
> separate policy system in for API keys unless they can control it. I
> don't think we can solve the "all clouds have the same policy for API
> keys" problem and I'd suggest putting that in the "too hard for now
> box". Thus we do your step 1, and leave step 2 until later when we have
> a better idea of how to do it without pissing off a lot of operators,
> breaking standard policy, or maintaining an entirely separate policy system.

This is definitely steps. And I agree we do step 1 to get us at least
revokable keys. That's Pike (hopefully), and then figure out the path
through step 2.

The thing about the policy system today, is it's designed for operators.
Honestly, the only way you really know what policy is really doing is if
you read the source code of openstack as well. That is very very far
from a declarative way of a user to further drop privileges. If we went
straight forward from here we're increasing the audience for this by a
factor of 1000+, with documentation, guarantees that policy points don't
ever change. No one has been thinking about microversioning on a policy
front, for instance. It now becomes part of a much stricter contract,
with a much wider audience.

I think the user experience of API use is going to be really bad if we
have to teach the world about our policy names. They are non mnemonic
for people familiar with the API. Even just in building up testing in
the Nova tree over the years mistakes have been made because it wasn't
super clear what routes the policies in question were modifying. Nova
did a giant replacement of all the policy names 2 cycles ago because of
that. It's better now, but still not what I'd want to thrust on people
that don't have at least 20% of the Nova source tree in their head.

We also need to realize there are going to be 2 levels of permissions
here. There is going to be what the operator allows (which is policy +
roles they have built up on there side), and then what the user allows
in their API Key. I would imagine that an API Key created by a user
inherits any roles that user has (the API Key is still owned by a
project). The user at any time can change the allowed routes on the key.
The admin at any time can change the role / policy structure. *both*
have to be checked on operations, and only if both succeed do we move

I think another question where we're clearly in a different space, is if
we think about granting an API Key user the ability to create a server.
In a classical role/policy move, that would require not just (compute,
"os_compute_api:servers:create"), but also (image, "get_image"), (image,
"download_image"), (network, "get_port"), (network, "create_port"), and
possibly much more. Missing one of these policies means a deep late
fail, which is not debugable unless you have the source code in front of
you. And not only requires knowledge of the OpenStack API, but deep
knowledge of the particular deployment, because the permissions needed
around networking might be different on different clouds.

Clearly, that's not the right experience for someone that just wants to
write a cloud native application that works on multiple clouds.

So we definitely are already doing something a bit different, that is
going to need to not be evaluated everywhere that policy is current
evaluated, but only *on the initial inbound request*. The user would
express this as (region1, compute, /servers, POST), which means that's
the API call they want this API Key to be able to make. Subsequent
requests wrapped in service tokens bypass checking API Key permissions.
The role system is still in play, keeping the API Key in the box the
operator wanted to put it in.

Given that these systems are going to act differently, and at different
times, I don't actually see it being a path to madness. I actually see
it as less confusing to manage correctly in the code, because they two
things won't get confused, and the wrong permissions checks get made. I
totally agree that policy today is far too complicated, and I fear
making it a new related, but very different task, way more than building
a different declarative approach that is easier for users to get right.

But... that being said, all of this part is Queens. And regardless of
how this part falls out, the Pike work to just provision these API Keys
looks the same.


Sean Dague

More information about the OpenStack-dev mailing list