Open Stack

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.

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.

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