Open Stack

See inline.

 

Jason

 

From: andi abes [mailto:andi.abes at gmail.com] 
Sent: Wednesday, June 15, 2011 5:04 PM
To: Rouault, Jason (Cloud Services)
Cc: Ziad Sawalha; openstack at lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

 

Jason,  

  Sounds like the model you're proposing could be achieved by  something
like this:

 

On Keystone:

- Roles are identified by name and contain tuples in the form of:

 -- the service to which this permission applies (e.g. service nova, swift).
Including the service is meant to side track attempts to normalize actions
across very different types of services

 --  the type of target this action applies to - e.g.  volume, network port
etc.

 -- action this permission allows - e.g. start vm, create volume.

 

- An authorize API call which accepts: 

 - the service requesting the authorization

 -  user token (from a previous authentication) 

 - tenant ID (to resolve the realm of the user token)

 - a target type

 -  the attempted action.

 

 This API would lookup the token, and if its present combine a set of the
relevant permissions from all the roles the token is referencing. If the
requested tuple exists in this combine set, the request is authorized.

 

A few caveats remain:

 

a) the above description doesn't include Resource Groups... as Ziad
mentioned, that is currently differed. When those are introduced, the
service should probably pass the instance-id of the target, and Keystone
would have to take that into account.
JLR>>  I think there are a number of ways to account for this if we
leveraged a hierarchical (URI) structure and allowed for wild carding. 

 

b) the current API's in keystone allows a service to perform actions on
multiple instances across tenants (containers) efficiently - a service could
obtain a list of accessible tenants and cache it. If only the 'authorize'
API is available, the service would need to perform a check with keystone
for every instance 

JLR>> Please explain the model for Tenant, Accounts, Projects, Groups,
Roles.. I have not been able to discern how tenant will map to accounts and
projects.  In any case, there are things that can be done to improve the
potential overhead of authorization calls. however, you will not eliminate
it completely.  That is the price you pay for increased security.  If
authorization is pluggable, operators can determine if and how they want to
use it.

 

c) In this model it is required to populate role definitions into keystone,
for all services. Since keystone should be independent of other services,
the set of actions/targets should probably be considered as ""data"" for it
- requiring a deployment step of sorts to make keystone aware of these
roles.

This could be avoided if the authorization decision is looked at as 2
separate steps:

 1. figure out what roles a user posses. 

 2. expand the set of roles to set of actions allowed

 3. determine if the action attempted is allowed

 

JLR>> Each service would need to document its target structure and actions
(this would be very similar to their published API's).  I think there would
be a default set of roles and permissions pre-populated to satisfy the base
set of use cases.     

 

it is obviously debatable where keystone ends and the services begin. In the
model above, keystone is responsible for all 3 steps via the authorize API.
I *think* the current API provides a very similar model, with the line drawn
at 1 - i.e. keystone provides to roles, and there is a separate middleware
piece to perform 2 & 3, executing in the request pipleline of the service.
Where this middleware executes (i.e. what is the API boundary to keystone)
doesn't necessarily change the overall model. 


JLR>>  Without a pluggable authorization system, operators will never be
able to provide fine-grained access control without mucking with hardcoding
in the API layer.  That is not a good path

 

I *think*.

 

 

 

 

 

 

 

 

On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services)
<jason.rouault at hp.com> wrote:

 

In my opinion the services (and their developers) should not need to
interpret roles thus resulting in varying semantics.  Roles should be
defined by a set of configurable privileges to perform certain actions on
specific targets for particular services.   The API should only need to know
to check with an authorization subsystem whether the incoming request is
allowed based on the who is making the request and the 3-tuple mentioned
previously.  

 

Jason

 

 

From: andi abes [mailto:andi.abes at gmail.com] 
Sent: Wednesday, June 15, 2011 9:18 AM
To: Rouault, Jason (Cloud Services)
Cc: Ziad Sawalha; openstack at lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

 

I would expect that the API of each service would have to interpret the role
assigned to a user in the context of that service - roles for swift nova
glance quantum etc would probably carry very different semantics.

 

So, to my understanding, key stone provides authentication and user
information - what tenants the user has access to, and what roles the user
is assigned. The mapping of these to what the user can do on what instances
in each service are left for the service to determine.

 

On Wed, Jun 15, 2011 at 10:32 AM, Rouault, Jason (Cloud Services)
<jason.rouault at hp.com> wrote:

Is there a plan to also have Keystone be the centralizing framework around
authorization?   Right now it looks like policy enforcement is left to the
API layer.

 

Thanks,

Jason

 

From: openstack-bounces+jason.rouault=hp.com at lists.launchpad.net
[mailto:openstack-bounces+jason.rouault
<mailto:openstack-bounces%2Bjason.rouault> =hp.com at lists.launchpad.net] On
Behalf Of Ziad Sawalha
Sent: Friday, June 10, 2011 5:24 PM
To: openstack at lists.launchpad.net
Subject: [Openstack] OpenStack Identity: Keystone API Proposal

 

Time flies! It's June 10th already. In my last email to this community I had
proposed today as the day to lock down the Keystone API so we can finalize
implementation by Diablo-D2 (June 30th).

 

We've been working on this feverishly over the past couple of weeks and have
just pushed out a proposed API here:
https://github.com/rackspace/keystone/raw/master/keystone/content/identityde
vguide.pdf

 

For any and all interested, the original source and code is on Github
(https://github.com/rackspace/keystone
<https://github.com/rackspace/keystone/raw/master/keystone/content/identityd
evguide.pdf> ), along with the current implementation of Keystone, examples,
sample data, tests, instructions, and all the goodies we could muster to put
together. The project also lives on Launchpad at
http://launchpad.net/keystone.

 

The API we just put out there is still a proposal. We're going to be
focusing on the implementation, but would still love to get community input,
feedback, and participation.

 

Have a great weekend and regards to all,

 

Ziad

 

 

 

 

 
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of
the
individual or entity to which this message is addressed, and unless
otherwise
expressly indicated, is confidential and privileged information of
Rackspace.
Any dissemination, distribution or copying of the enclosed material is
prohibited.
If you receive this transmission in error, please notify us immediately by
e-mail
at abuse at rackspace.com, and delete the original message.
Your cooperation is appreciated.


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110616/df066690/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4854 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110616/df066690/attachment.bin>