Open Stack

On 11/28/2012 06:00 PM, Matt Joyce wrote:
> Adam,
>
>    In this model can I do a...
>
>    grant trust key for user foo that is read on keystone, constrained 
> to tenant uuid bar  ?
Yes.

"read on keystone" might need to be slightly more defined, as it needs 
to be something controlled by policy.  So lets say a user has the 
"read_keystone" role (we might want to make a handful of implicit roles 
that every user has on all tenants...interesting thought)  tehn you 
would add that role to the trust:


The create call would have a payload along these lines.
{
   trustor: foo,
   trustee:  cinder,
   tenant: bar,
   roles: [read_keystone],
   endpoints: [https://10.10.2.1/keystone/]
}

And you hould be able to see how that would map to the tokens.



>
>    That's probably enough for my needs.
>
> -Matt
>
> On Wed, Nov 28, 2012 at 2:53 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 11/28/2012 05:23 PM, heckj wrote:
>
>         To be a little more specific, what I'm trying to understand is
>         the workflow beyond the initial request to a service with the
>         trust concept already set up -
>
>         Say Joe requests a snapshot to be taken of a volume, and wants
>         that dumped into object storage. The service doing the
>         snapshot takes a while (sorry, it's just slow) - and 30
>         minutes later the service (cinder in my little example) wants
>         to write data to object storage (swift) - what allows this to
>         happen? What interactions and with what data stored where?
>
>     OK, let me get a better write up going.  I'll try to post
>     something in the next couple of days as far as how I think this is
>     supposed to work, but the short form:
>
>
>     user joe creates a trust.  trustor is joe, trustee is cinder,
>     tenant is joes_restaurant (eat at Joes!) and the role is what ever
>     is required to write to swift, so we will call it swift_write.
>
>     when cinder goes to perform the action for joe, it authenticates
>     to keystone passing its service token and the trust id.  In
>     return, it gets back a token that has joe as the user_id, as well
>     as all the other information specified by the trust.  It uses that
>     token to write to swift.
>
>     So swift would have to be modified to know about trusts.
>
>     so the APIs would be something like
>
>     POST v3/trusts  (create a new one)
>     DELETE v3/trusts/<id>  (create a new one)
>     POST v3/tokens (get a token for a trust)
>
>     But I'll write it up in more detail.
>
>
>
>
>         -joe
>
>         On Nov 28, 2012, at 2:14 PM, heckj <heckj at mac.com
>         <mailto:heckj at mac.com>> wrote:
>
>             Hey Adam -
>
>             so what I'm missing on all of this is
>
>             1) what's the API and how does a service and user interact
>             with it?
>
>             2) what's the gist of the code - have it in a github repo
>             or something to see your initial implementation?
>
>             Trust, delegation, impersonation - whatever - the need
>             that you laid out in your blog post is great. Glance and
>             Nova have the exact same needs
>             (the blog post isn't a spec, by the way - you should
>             update the BP to point to something other than your
>             motivations for making it)
>
>             In terms of the choices, I'd like to see the API and how
>             you've taken a stab at implementing it to suggest some
>             possible solutions. With no other knowledge, I'm tempted
>             to assert it should be it's own backend, even knowing
>             that's relatively heavy weight.
>
>             -joe
>
>             On Nov 28, 2012, at 7:45 AM, Adam Young <ayoung at redhat.com
>             <mailto:ayoung at redhat.com>> wrote:
>
>                 I have a very rudimentary Trust  (what I used to call
>                 Preauth
>                 https://blueprints.launchpad.net/keystone/+spec/trusts) implementation
>                 working with the SQL backend for Identity.
>
>                 With LDAP, I am not sure where I would store the trust
>                 information. The data for the trust itself is simply
>                 the uuid user_ids for the trustor and  trustee and
>                 tenant Id.  There is also a table for the roles, and a
>                 second table for the endpoints associated with the
>                 trust.While we could shoehorn this into the user
>                 object, I am not sure that there is an intuitive way
>                 to implement it in LDAP.
>
>                 I see three choices.
>
>                 1.  Leave the Trusts in the identity schema.  This has
>                 the nice effect of keeping the user-ids as foreign
>                 keys.  It has the drawback of forcing an LDAP backend
>                 solution.
>                 2.  Move the Trusts into the Token backend.  This will
>                 get avoid the issue of LDAP support.  It does mean
>                 that tokens, which is a schema that is high volume,
>                 read intensive, and populated by short lifespan
>                 entities, gets mixed with trusts, which is low volume,
>                 and long lived.
>                 3. Move it into its own backend.  This seems a little
>                 heavy weight.
>
>
>                 Thoughts?
>
>                 _______________________________________________
>                 OpenStack-dev mailing list
>                 OpenStack-dev at lists.openstack.org
>                 <mailto: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
>             <mailto: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
>         <mailto: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
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121129/be0a47a5/attachment.html>