Open Stack

On 18/05/17 09:23, Monty Taylor wrote:
>
> But think of the following use cases:
>
> As a user, I want to make an API key that I'm going to use for general
> automation just like I use my Password auth plugin based user account
> today. I want it to be able to do everything I can do today - but I
> value the revocation features.
>
> As a user, I want to make an API key that can only upload content to
> swift. I don't want to have to list every possible other API call.
>
>
> What if we think about it like this:
>
> For step one:
>
> - A User creates an API Key in a Project. It will be a blacklist Key.
> - That API Key is created with identical role assignments to the User
> that created it.
> - The role assignment clone is done by keystone and is not tied to the
> User's ability to perform role assignments
> - All API Keys are hardcoded in keystone to not be able to do
> (POST,DELETE) /projects/{project_id}/api-key
> - All API Keys are hardcoded in keystone to not be able to do
> (POST,PATCH,DELETE) /users
> - All API Keys are hardcoded in keystone to not be able to do
> (POST,PATCH,DELETE) /projects/{project_id}
>
> For step two:
> - A User creates a whitelist API Key. It can't do ANYTHING by default,
> no further action is needed on API key restrictions.
> - A User creates a blacklist API Key. All API Key restrictions from step
> one are added as initial blacklist filters.
>
> The change in step two would allow a User to decide that they want to
> opt-in to letting an API Key do *dangerous* things - but it would
> require explicit action on their part ... even if they have requested a
> blacklist Key.
>
> We should also potentially add a policy check that would disallow a User
> from removing the API Key blacklist exclusions, since it's possible and
> reasonable that an Admin does not want a User to be able to create keys
> that can manage keys.

I'd encourage everyone to read this excellent blog post on how it works 
in AWS:

http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/

TL;DR: a policy document contains a Principal, an Action, a Resource and 
a Condition (like e.g. validity time). You can attach this policy 
_either_ to an IAM account (i.e. a User or Role - 'Role' being the 
equivalent of an auto-provisioned API key), in which case that account 
is assumed to be the Principal, _or_ to a resource (e.g. an S3 bucket), 
in which case that is assumed to be the Resource. AWS services 
themselves can also be Principals. IIUC access is default-deny and you 
open up individual stuff with a "Effect": "Allow" rule, but you can open 
up everything by setting  "Action": "*" and then blacklist stuff by 
adding "Effect": "Deny" rules.

When we're designing the initial API we need to keep in mind that the 
next stage will require a comparable level of sophistication to this.

cheers,
Zane.