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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
