Open Stack

On 02/13/2013 12:41 PM, Scott Devoid wrote:
> Hi Adam,
>
> These changes look interesting. I have two concerns from an operators
> perspective:
>
> 1. Cloud admins need the ability to impersonate users. It is already
> hard to tell how visible different resource types are and what
> permissions different users might have on a resource; with different
> permissions tied to different tokens, this gets more complex. Being
> able to actually see what a user sees goes a long way to resolving
> issues.
So, moving forward, trusts are a better way to impoersonate users. 
However, it an admin can get a token as a user today, that won't change 
in the  future.  It just means that they have to start from an unscoped 
token to get a scoped token.  This rule would be the same for admins and 
for end users.

>
> 2. Whatever enables the --all-tenants functionality in nova list needs
> to stay. And we need support for it against as many resources as
> possible.

One of the few things you can do using an unscoped token is Listing the 
set of tenants that a user is assigned to.  That will not change.

>
> I still don't quite understand the Keystone model, so these concerns
> could be orthogonal to what you are proposing. Let me know if that's
> the case.
>
> Thanks,
> ~ Scott
>
>
>
> On Wed, Feb 13, 2013 at 11:15 AM, Adam Young <ayoung at redhat.com> wrote:
>> David,
>>
>> All good questions.  On this, as on most things, I think we are in a similar
>> mindset.  My concern is not getting the token abstraction correct, but the
>> fact that what I am proposing will break some form of backwards
>> compatibility.
>>
>> I'm concerned that by focusing too much on the theoretical, I won't get the
>> resolution I need to move forward before the code freeze.
>>
>> I'll try to answer your questions in line.
>>
>>
>>
>> On 02/13/2013 11:15 AM, David Chadwick wrote:
>>> Hi Adam
>>>
>>> I think you need to look at this from the modelling perspective first
>>> before deciding upon the solution to your problem. The first thing to ask,
>>> is what is (the conceptual model of) a token that is being used by Keystone.
>>> A token could either contain
>>>
>>> i) a set of permissions or
>>> ii) a pointer to a set of permissions held external to the token.
>>>
>>> A token can either be
>>> a) opaque or
>>> b) transparent
>>> to any observer. It would be preferable to say it should always be opaque,
>>> but I dont think this is currently the case.
>> Correct.  Even PKI based Tokens are really transparent.
>>
>>
>>
>>> A token could either be
>>> 1. Validatable directly by the recipient
>>> 2. Only validated by the issuer
>>> I think V2 is 2. and V3 is 1. but I could be wrong.
>> You are correct,except for the versioning.  V2 supports both UUID and PKI
>> based tokens.  V3 will support both as well.  UUID tokens must be validated
>> by the issuer, PKI can be validated by the recipient. SHA  HASHes of the PKI
>> tokens may be used like UUID tokens as well, for size constraint reasons.
>>
>>> A token can be one time use or many time use. I think that currently it is
>>> the latter.
>> Correct
>>
>>> A token can be a bearer token or tied to the holder (of the permissions).
>>> Currently I believe it is a bearer token.
>> Correct. And I agree that it is wrong.
>>
>>
>>> I dont fully know what the current Keystone token model is, or if it is
>>> documented anywhere.  Do you know? I have made my best guesses above for the
>>> answers I think I know.
>>>
>>> Now to your specific questions
>>>
>>> On 13/02/2013 14:33, Adam Young wrote:
>>>> Right now, Keystone will allow you to get a token based on a previous
>>>> token.   It does not matter if the original token is for a different
>>>> scope, more restricted, than the second token.
>>>>
>>> If the token is modelled as a set of permissions, then it should not be
>>> possible to get an increased set of permissions from a token since where
>>> would they come from? Only an equal or reduced set of permissions should be
>>> swappable for the original token.
>> That is what I am trying to accomplish.  There may be more elegant ways to
>> do this, but my recommendation is the simplest.  Two kinds of tokens, and
>> only unscoped can be used to get another token. I see it as an analogue to
>> TGTs in Kerberos.
>>
>>> If a token is a pointer to a (super)set of permissions, then it should be
>>> possible to ask for any subset of permissions from the superset.
>>>
>>> My feeling is that perhaps the current token is both:
>>> a (pointer to) a subset of permissions of the user and
>>> a pointer to the superset of permissions of the user. Is this the case?
>> I'd have to think about it, but I don't think it is a superset.  At least,
>> there is no case that I know of where a token contains anything that is not
>> in the set of permissions associated to the user directly.
>>
>>
>>>> While writing the trusts implementation, I realize that carrying this
>>>> rule forward would open up a security hole.  A user with a token based
>>>> on a trust would be able to get a new token for any of the privileges of
>>>> the trustor.  The whole point of trusts was to scale down the scope of
>>>> access from a token, not to increase it.
>>>
>>> There is clearly a big hole in either the token or trusts model or both if
>>> this is the case.
>> Agreed. And, while I could fix it in the trusts model, I think it is
>> worthwhile to fix it for all tokens.
>>
>>
>>> If I have a delegated permission (which you call a trust), then this is my
>>> permission that was delegated to me. I am not the delegator so I cannot get
>>> any of the permissions belonging to him. Furthermore any token I might have
>>> that contains my delegated permission, is my token and does not belong to
>>> the delegator (though he can revoke it), nor does it hold the delegator's
>>> permissions. It holds the delegator's delegated permissions. The delegator
>>> still has his own permissions in his own tokens.
>>
>> So the fix I could put in place is that you cannot use a trust-issued token
>> to get another token.  I am just going for an even-more-strict rule than
>> that.
>>
>>
>>> So I dont see why, if your delegation model is correct, a delegate can
>>> ever get his hands on the permissions of the delegator. Something is broken
>>> if this is the case.
>> Agreed. I never understood the justification for the current implementation.
>> Bascially, though, any valid token for a user can be used to get another
>> token, even if the new token is scoped to another tenant/project.  I want to
>> remove this.
>>
>>
>>>> I would like to propose the following rule. It will have to apply to
>>>> both the V2 and V3 versions of the APIs.
>>>>
>>>> Only an unscoped token can be used to retrieve another token.
>>>
>>> It depends upon what your model of a token is, and this should be
>>> completely unrelated to delegation (trusts).
>>
>> Exactly.  Trusts is broken without it, but really, so is a lot of other
>> things.
>>
>>
>>>>
>>>> In order to get an unscoped token, you have to pass in userid and
>>>> password, or one of the REMOTE_USER mechanisms.
>>>> It is technically OK to use an unscoped token to get another token, so
>>>> long as the time out is honored, but I am not sure if that provides any
>>>> real benefit.
>>>>
>>>> I could make a one-off exception for trust tokens.  However, if we don't
>>>> address this issue now, I suspect it will come back to haunt us later.
>>>>
>>>> Here is a longer rationalization.
>>>>
>>>> Tokens are a symetric shared secret.
>>>
>>> Shared between whom? If this is your model of a token, I would suggest it
>>> is not at a high enough level. It does not say conceptually what the token
>>> is, but rather how it is implemented.
>> Shared between three parties:  the user, keystone, and the remote service.
>> Much of the workflow depends on remote services handing over tokens to other
>> remote services.  Trusts will provide a better mechanism for that, but we
>> need trusts in place before we can rework the other services.
>>
>>
>>>   If you have the token, you have
>>>> the permissions of the user.
>>>
>>> which user? The user to whom the token belongs? Then this is because your
>>> tokens are currently bearer tokens. So they effectively belong to anyone who
>>> can grab them.
>>
>> Yes, and My proposal does not fix this.  While I like your previous proposal
>> to put a public key into the token, I am not proposing that yet.  I am
>> probably more prone to use X509 than to further extend the token mechanism.
>> But that is a tale for another day.
>>
>>
>>>
>>>   Thus, a token should not be spread
>>>> around.
>>>
>>> Clearly not if they are bearer tokens.
>>>
>>>   Ideally, tokens should contain just the minimal amount of
>>>> permissions to accomplish the task at hand.
>>>
>>> Agreed
>>>
>>>   THat way, if they get
>>>> intercepted, they can only be used to do minimal amounts of damage.  If
>>>> a user has access to multiple projects (tenants), the token shoud not
>>>> provide access to the tenants other than the one for which it is
>>>> allocated.  Right now, due to token reissue,  a token for Project A can
>>>> be used to get a token for Project B.
>>>
>>> Not sure how this fits in with your model of a token being a shared secret
>>> :-)
>>>
>>>> In the future, we are talking about scoping tokens to domains,
>>>> endpoints, and other containers.  Lets choose now to limit the amount of
>>>> exposure on a single token.
>>>
>>> Lets choose first to have a clear model of what a token is now, and what
>>> we would like it to be in the future. Otherwise we are just building complex
>>> layers of spaghetti around some ambiguous ill conceived undocumented idea of
>>> what a token is or might be.
>> Technically, I am removing something that can currently be done now which I
>> consider dangerous. Like removing peanut oil from the spaghetti sauce.
>> Doesn't mean that we shouldn't have a solid model, just that this needs to
>> move forward on its own.
>>
>>
>>
>>> regards
>>>
>>> David
>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev