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

Sean Dague sean at dague.net
Thu May 18 11:53:49 UTC 2017

On 05/17/2017 09:34 PM, Adrian Turjak wrote:
> On 17/05/17 23:20, Sean Dague wrote:
>> On 05/16/2017 07:34 PM, Adrian Turjak wrote:
>> <snip>
>>> 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
>> forward.
>> 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
> Fully agree that expecting users of a particular cloud to understand how
> the policy stuff works is pointless, but it does fall on the cloud
> provider to educate and document their roles and the permissions of
> those roles. I think step 1 plus some basic role permissions for the
> Keys with the expectation of operators to document their roles/policy is
> a safe enough place to start, and for us to document and set some
> sensible default roles and policy. I don't think we currently have good
> documentation for what all the roles/policy actually let you do by
> default, or very clearly stating that by default most services work
> under the assumption "if you have a role in this project at all you can
> do most things".


> My worry about policy also is that I'm not sure how safe it is for a
> project owned API key to inherit permissions from the user who created
> it. I can't think of a better way to it though but I'm still slightly
> uncomfortable with it since a user with more roles could make a key
> with  a subset of those which then someone else in the project can reset
> the password for and then have access to a API key that 'may' be more
> powerful than their own user. In clouds like ours where we allow
> customers to create/manage users within the scope of their own projects,
> there are often users who have different access all in the same project
> and this could be an odd issue.

This is a super interesting point I hadn't considered, thanks for
bringing it up. We could probably address it by just blocking certain
operations entirely for APIKeys. I don't think we loose much in
preventing APIKeys from self reproducing. Blocking user/pw reset seems
like another good safety measure (it also just wouldn't work in
something like LDAP, because there is no write authority). That would be
a very good set of things to consider on Monty's spec of any APIs that
we're going to explicitly prohibit for APIKeys in iteration 1.

This is definitely a way in which they would be not like Users, and I
think brings up an important consideration about why they are a bit
different from users.

> As for step 2, as long as it honors the policy set by operators, and
> provides sensible errors to users when they've done something silly
> about setting a policy that the roles don't allow, then this should be
> fine. We just need to be really careful to integrate the two policy
> layers so they work well enough together regardless of whatever silly
> policy operators do themselves. I don't envy anyone that task.

Definitely will still honor operator policy, it will just have an
additional permissions check even before getting there. My feeling is
the 2 things being separate actually will make it easier to rationalize
the right thing to do. But, a lot of that will need

> The API keys may not solve some multi-project automation type things, so
> there users are going to still have to be used, and I'm not sure if API
> keys could really be made to work in multi-project unless at least we
> allow sub-project inheritance in some sense. I don't think we should
> allow multi-project ownership of API keys, but if the user creating it
> has inherited roles we can probably do something with that.

Yeh, multi project is going to be at least phase 3 (if not later). I can
vaguely see how in a hierarchy it's doable.


Sean Dague

More information about the OpenStack-dev mailing list