Open Stack

Addendum

If you can tie a token to an instance.  The API can tie that token to a
project.  And then you can automatically reduce the token's scope to a
project.

-Matt

On Thu, Jan 24, 2013 at 3:37 PM, Matt Joyce <matt.joyce at cloudscaling.com>wrote:

> A thought about tokens and cloud
> =========================
>
> Below is a quick thought I've been mulling over on and off in my free
> time.   It relates to how we build authentication structures for use inside
> of the cloud.
>
>
> The Dream
> ========
>
> Imagine if you will an alternate future:
>
> I spin up an instance on my openstack cloud.  I do NOT inject a key.  I
> instead try to log in directly using my keystone credentials ( whatever
> they may be, maybe two factor? ).  This means that cloud providers can cut
> perms on running instances remotely with simple changes to keystone or
> backend authentication systems.  They can also allow users to begin to
> login to systems they previously did not have access to without sharing
> keys or injecting anything into those instances.  In short this gets us non
> suck ACL control on instances from keystone.
>
> Some folks will point out this is not cross cloud friendly.  It's totally
> not.  And maybe IAM is the solution for that.  But maybe we'll need this
> for real IAM support.
>
> The history
> ========
>
> A long while back I tried to build pam authentication services for
> keystone.  This was a great idea that resulted in terrible failure.
>
> The fundamental problem I ran into basically stems from all ssh clients
> wanting to perform an getpwnam() on a user requesting to authenticate
> BEFORE handing auth creds off to PAM.
>
> In short, if the instance can't query by user name for posix schema
> information ( uid, gid, home_dir, etc ) BEFORE any authentication query can
> occur the authentication will fail.  And there is just no way around that
> without modifying the way ssh works.  Which is probably never going to
> happen as the radius folks have tried and failed for years to do so.
>
> So what we need is an NSS ( Name Switch Service ) access to keystone.
>
> I mean sure,  if you backend to LDAP and allow anonymous read queries from
> your instance network space, you can just use the nss module to ldap.
> However that's not very portable between openstack clouds.  And it means
> building administrative utilities for LDAP in addition to openstack.
>
> But the problem becomes more fundamental when you consider the issue....
>
> The problem
> =========
>
> This got me to thinking about the fundamental nature of cloud instances
> and performing any sort of elevated permissions query or unauthenticated
> query to our APIs.  We need a service ticket functionality but we can't
> protect anything we place on instances.
>
> However instances can be fully qualified as part of the cloud.  You can in
> effect tie a token to an instance and ensure that when the token is used
> it's being used on an instance it's intended for.  Do we want that?  What
> does it get us REALLY?
>
> Then there's single use tokens...  do they get used once and die?  do they
> only allow for a reduced set of queries?  can there bet a getpwnam only
> token?
>
> In effect the issue we face is a very complex one.  I don't think we
> should try to solve every problem, but we will want a token structure that
> is flexible as we can possibly make it.  Because there's a good chance
> we'll end up running in a few different directions before we settle on
> something we like.  And I don't want use to be revisiting token structure
> in v4 api.
>
> Token Structure
> ============
>
> looking at the straw man...
>
>
> {
> user : { id,  other user specific attributes },
> domain : {id},
> project : { roles [role ids]},
> auth_mechanisms[],
> services:[
>     compute: [https://nova/endpoint],
>     identity: [https://keystone/endpoint],
> ...
> ]
> }
>
> We'll want for the user attributes to be expandable to include things like
> posix schema... or windows domain schema... or who knows.
>
> Domain ID works for me... but I am a fan of comment fields that can be
> NULL but also be there in case someone  wants to send some extra info down
> the line.
>
> projects...  an interesting question.
>
> I think the multiple token spanning token is... interesting.  I think
> roles could be an answer for some of the ACL control for a token... but i
> have not trodden that path yet.
>
>
> projects : [{ id: id1, roles [role1, role2]}, { id: id2, roles [role1,
> role3]},
>
> service identifiers are great.  again you may want to make internal vs
> public url tokens that are idenfitied as such on the backend... with a
> quick identifier on the front end just to let you know they are?
>
> I think also on the backend allowing a token to be reserved for use with a
> specific instance id and a means to verify that instance id is the query
> origin.
>
> I think that matters.
>
> Also the question for external queries becomes an issue.  What happens
> when i need to make a query from outside to the publicurl by nest some
> internal query structure?  No idea if we'd ever need to... but it's good to
> leave an area to plug something in if we need it.
>
>
> Conclusion
> ========
>
> I don't have one.
>
> Just a few thoughts.  And I think they can help.
>
> -Matt
>
>
>
>
> On Thu, Jan 24, 2013 at 7:03 AM, Adam Young <ayoung at redhat.com> wrote:
>
>> On 01/24/2013 04:06 AM, David Chadwick wrote:
>>
>>>
>>>
>>> On 24/01/2013 00:50, Adam Young wrote:
>>>
>>>>
>>>>> By the way, introducing holder of key into tokens solves the bearer
>>>>> problem and does not require SSL/TLS. What it requires is simply that
>>>>> the client signs the message containing the token with the key and
>>>>> includes a nonce/timestamp in the signed message so that the recipient
>>>>> can validate that the user is the holder of the token and the token
>>>>> has not been replayed.
>>>>>
>>>> Are you saying that the whole web requests would then be signed? Yes,
>>>> that would work, and would be very effecient, but it would require
>>>> extending all of the HTML aware parts to allow for signatures. I think
>>>> that would be a  very valuable extension.
>>>>
>>>
>>> The body of the POST needs to be signed. This does not stop a MITM, but
>>> then neither does SSL if you have a forged cert in the name of the sender.
>>>
>>> David
>>>
>>
>> Just thinking this through:
>>
>> Keystone still is the authority on keys and signing, so I think this
>> might actually prevent a man-in-the-middle attack.  The key signed in the
>> token is the one used to sign the message.  The token is signed by the
>> keystone server.  The token is authenticated against keystone.   So a man
>> in the middle either has to try to use the secret key associated with the
>> public key from the token, which they won't have access to, or they have to
>> inject their own key.
>>
>> If they inject their own key, they need to get a new token.  Which means
>> they would need to convince Keystone that they are the original user, and
>> that keystone should sign a different key.  That is a pretty high barrier
>> to overcome.
>>
>>
>> Am I missing something?
>>
>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130124/d5c2ea8a/attachment.html>