[Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

Bryan D. Payne bdpayne at acm.org
Tue Oct 23 17:09:31 UTC 2012


I wanted to throw in my two cents here.  I generally agree with the
notion that we should have the ability to issue tokens with different
scopes.  And that this will become increasingly useful down the road
as we seek to provide finer grained access control for each user.
Having said this, I do have a few thoughts about providing a token
with such broad access as to include multiple tenants / projects.

1) If such a token is compromised, the impact would be significantly
greater (than compromising a token valid for only one tenant).  I
would rather have limited permissions "on the wire" and then trust the
clients to use and manage multiple credentials correctly.  For
example, in this case a client could have a token to access each
tenant, and then access them separately from the client side to
perform operations as needed.  Thereby requiring an attacker to
compromise multiple connections to achieve the same goal, under some
scenarios.

2) Providing fine grained access control is great.  I think there's a
security question here, though, about how coarse we are willing to go.
 Would we feel comfortable issuing a token that provides full access
to the cloud?  I would not.  Would we feel comfortable issuing a token
that provides full access across multiple tenants?  I would not.
Would we feel comfortable issuing a token that provides access for a
single tenant, ideally for a single or small number of tenant
operations?  This is what I would like to see.

3) Finally, there's a valid question about whether we should allow
OpenStack users to make these choices for themselves.  And then,
within Keystone, provide some sensible defaults.  The risk that I see
here is that we would be potentially making this security critical
code more complex, while at the same time splintering our user
community such that each configuration has fewer users and testers.

I think it's clear that we don't want the only option to be
multi-tenant tokens.  Given the added risk described in (3), I think
that we should better understand how much complexity would be added in
the code to optionally enable multi-tenant tokens, and what the use
cases are that motivate this feature in the first place.  Only then
can we make an informed decision on the risk / benefit tradeoff
involved here.

Cheers,
-bryan




More information about the Openstack mailing list