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

Adrian Turjak adriant at catalyst.net.nz
Thu May 18 01:34:56 UTC 2017



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.

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.

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.




More information about the OpenStack-dev mailing list