Re: [Openstack] Keystone tenants vs. Nova projects

[Yuriy Taraday]

I got it. We need to create something like domain-wide backend
configuration. Domain can contain several tenants and users and should be
explicitly specified in authentication data.
The only problem I see here is security. If I have a cloud and provide
access to it to some company, they are free to create any tenant and user
they want, so they can gain access to part of cloud that wasn't dedicated to
them.
This can be solved either by tweaking services to handle user, roles and
tenants on per-domain basis or by adding (maybe in @-style) domain to all
this names in all requests that are expected from cloud services (like
validate_token).

Kind regards, Yuriy.

On Fri, Jul 15, 2011 at 23:11, andi abes  wrote:

> Just to clarify - yuriy, what you're describing is very reasonable for an
> enterprise system, where you definitely strive to achieve centralized
> authentication. I however believe that model is too restrictive for a cloud
> service provider. These two worlds are somewhat different.
>
> On Jul 15, 2011, at 15:07, andi abes  wrote:
>
> I guess sfdc disagrees with you - they allow e.g Dell to use a single sign
> on to authenticate to their services - as a @dell user, you can login with
> the same email/password to internal resources as well as sfdc ones. ( in
> case it's not obvious - you also update your password in one location - the
> Dell AD directory)
>
> On Jul 15, 2011, at 14:14, Yuriy Taraday < 
> yorik@gmail.com> wrote:
>
> Currently there is a basic skeleton for only one backend (identity
> store) configuration per Keystone instance. It can be either DB or LDAP (the
> latter is almost done).
> May be in future we should be somehow able to specify not only tenants but
> also an backend for each authentication request.
> But I cannot imagine a real use case for that. All identities should be
> stored in one place. I doubt that it'll be useful to keep different users
> and/or tenants (or roles or whatever) in different stores. There usually is
> one single central repository, DB, LDAP or may be some billing system. If we
> have two isolated systems, we should consider using two separate auth
> services.
>
> Kind regards, Yuriy.
>
>
> On Fri, Jul 15, 2011 at 21:40, andi abes < 
> 
> andi.a...@gmail.com> wrote:
>
>> Yuriy,
>>
>> a  use-case scenario for keystone would be a service provider servicing
>>  large customers with  their own  authentication infrastructure (e.g. LDAP/
>> AD etc). Obviously, different tenants  have different instances. To
>> authenticate a user, the correct authentication back end must be selected.
>>
>> In your model, how would a service provide be able to allow delegated
>> authentication to different customers?
>>
>>
>> On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday < 
>> 
>> yorik@gmail.com> wrote:
>>
>>> I think, there should not be such thing as default tenant.
>>> If user does not specify tenant in authentication data, ones token should
>>> not be bound to any tenant, and user should have access to resources based
>>> on global role assignments.
>>> If user specify tenant, one should be either explicitly bound to tenant
>>> (probably through UserRoleAssignment model, but it is not the best way) or
>>> in some global role. Then one will have access to resources based on global
>>> role assignments and tenant role assignments.
>>> I'm not sure whether users should be added to a tenant and then to roles
>>> in this tenant or we should remove totally direct link between user and
>>> tenant, so that user is in tenant if and only if one is in any role in this
>>> tenant.
>>>
>>> Kind regards, Yuriy.
>>>
>>>
>>> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh 
>>> <
>>> liem_m_ngu...@hp.com> wrote:
>>>
  When one creates a user, should a user always have a tenant associated
 with her?  If that’s the case, then the “default” tenant is the tenant that
 the user is associated with at creation time?  Sorry for responding to the
 question with another question, but it is unclear for me from looking at 
 the
 model (there is no non-null constraint on the tenant_id fk on the user
 table).

 ** **

 Thanks,

 Liem

 ** **

 *From:* openstack-bounces+liem_m_nguyen= 
 hp.com@  
 lists.launchpad.net 
 [mailto:openstack-bounces+liem_m_nguyen=
 hp.com@  
 lists.launchpad.net] *On Behalf Of *Ziad Sawalha
 *Sent:* Thursday, July 14, 2011 12:22 PM

 *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
  
 openstack@lists.launchpad.net
 *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects

  ** **

 In the example I gave below they are not members of any group and have
 no roles assigned to them. Should they still be authenticated?

 ** **

Re: [Openstack] Physical host identification

[Chris Behrens]

I think it's sensitive because one could figure out how many hosts a SP has 
globally... which a SP might not necessarily want to reveal.

- Chris


On Jul 15, 2011, at 3:34 PM, karim.allah.ah...@gmail.com wrote:

> On Fri, Jul 15, 2011 at 11:31 PM, Chris Behrens  
> wrote:
> Nevermind.  Just found a comment in the API spec that says "hostID" is unique 
> per account, not globally.  Hmmm...
>  
> This is weird ! I can't find anything in the code that says so !! hostID is 
> just a hashed version of the 'host' which is set as the 'hostname' of the 
> physical machine and this isn't user sensitive. So, It's supposed to be a 
> global thing !
> 
> Can somebody explain how this is a user sensitive ?
>  
> 
> 
> On Jul 15, 2011, at 2:27 PM, Chris Behrens wrote:
> 
> > I see the v1.1 API spec talks about a 'hostId' item returned when you list 
> > your instances (section 4.1.1 in the spec).  These should be the same 
> > thing, IMO.
> >
> > I think you're right, though.  I don't believe we have any sort of 'hostId' 
> > today, since hosts just become available by attaching to AMQP.
> >
> > - Chris
> >
> > On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:
> >
> >> I understand that we're all familiar with virtualization and its benefits. 
> >> However, in the Real World, those of us who run clouds often need to work 
> >> with physical devices. I've proposed a blueprint and spec for a /hosts 
> >> admin API resource that would return information on physical hosts. 
> >> However, I don't believe that there's any way for us to actually identify 
> >> a specific server (I'm actually hoping I'm mistaken about this, because 
> >> that would make my life easier).
> >>
> >> So, to get information about a specific host, you'd use /host/{id} — but 
> >> what should go in the {id} slot?
> >>
> >> We'd also like to include this data elsewhere; for example, in error 
> >> messages, it might help to know the physical device on which a server is 
> >> created.
> >>
> >>
> >> 
> >> This email may include confidential information. If you received it in 
> >> error, please delete it.
> >> ___
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> 
> This email may include confidential information. If you received it in error, 
> please delete it.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Karim Allah Ahmed.
> LinkedIn
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Physical host identification

[karim.allah.ah...@gmail.com]

On Fri, Jul 15, 2011 at 11:31 PM, Chris Behrens  wrote:

> Nevermind.  Just found a comment in the API spec that says "hostID" is
> unique per account, not globally.  Hmmm...
>

This is weird ! I can't find anything in the code that says so !! hostID is
just a hashed version of the 'host' which is set as the 'hostname' of the
physical machine and this isn't user sensitive. So, It's supposed to be a
global thing !

Can somebody explain how this is a user sensitive ?


>
>
> On Jul 15, 2011, at 2:27 PM, Chris Behrens wrote:
>
> > I see the v1.1 API spec talks about a 'hostId' item returned when you
> list your instances (section 4.1.1 in the spec).  These should be the same
> thing, IMO.
> >
> > I think you're right, though.  I don't believe we have any sort of
> 'hostId' today, since hosts just become available by attaching to AMQP.
> >
> > - Chris
> >
> > On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:
> >
> >> I understand that we're all familiar with virtualization and its
> benefits. However, in the Real World, those of us who run clouds often need
> to work with physical devices. I've proposed a blueprint and spec for a
> /hosts admin API resource that would return information on physical hosts.
> However, I don't believe that there's any way for us to actually identify a
> specific server (I'm actually hoping I'm mistaken about this, because that
> would make my life easier).
> >>
> >> So, to get information about a specific host, you'd use /host/{id} — but
> what should go in the {id} slot?
> >>
> >> We'd also like to include this data elsewhere; for example, in error
> messages, it might help to know the physical device on which a server is
> created.
> >>
> >>
> >> 
> >> This email may include confidential information. If you received it in
> error, please delete it.
> >> ___
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
>
> This email may include confidential information. If you received it in
> error, please delete it.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Karim Allah Ahmed.
LinkedIn 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account

[Nguyen, Liem Manh]

Hi,

For Nova, the Keystone Tenant maps to a Nova project, and according to the 
"Finalize Auth integration" blueprint, the Nova project is going away ("no more 
project/roleuser info in nova").

What about Swift's account?  I assume the Keystone tenant would map to a Swift 
account.  How would this mapping occur?  Would Swift still maintain account 
information in the db and these will get synchronized with Keystone tenant 
information (i.e., auto-create accounts), or would Swift get rid of the account 
concept and have a mapping between tenant and containers instead?  If there is 
any existing blue-print/docs on Keystone/Swift integration plan for Diablo, 
that would be greatly appreciated.

Thanks,
Liem
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Physical host identification

[Chris Behrens]

I see the v1.1 API spec talks about a 'hostId' item returned when you list your 
instances (section 4.1.1 in the spec).  These should be the same thing, IMO.

I think you're right, though.  I don't believe we have any sort of 'hostId' 
today, since hosts just become available by attaching to AMQP.

- Chris

On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:

> I understand that we're all familiar with virtualization and its benefits. 
> However, in the Real World, those of us who run clouds often need to work 
> with physical devices. I've proposed a blueprint and spec for a /hosts admin 
> API resource that would return information on physical hosts. However, I 
> don't believe that there's any way for us to actually identify a specific 
> server (I'm actually hoping I'm mistaken about this, because that would make 
> my life easier). 
> 
> So, to get information about a specific host, you'd use /host/{id} — but what 
> should go in the {id} slot?
> 
> We'd also like to include this data elsewhere; for example, in error 
> messages, it might help to know the physical device on which a server is 
> created. 
> 
> 
> 
> This email may include confidential information. If you received it in error, 
> please delete it.
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Physical host identification

[Chris Behrens]

Nevermind.  Just found a comment in the API spec that says "hostID" is unique 
per account, not globally.  Hmmm...


On Jul 15, 2011, at 2:27 PM, Chris Behrens wrote:

> I see the v1.1 API spec talks about a 'hostId' item returned when you list 
> your instances (section 4.1.1 in the spec).  These should be the same thing, 
> IMO.
> 
> I think you're right, though.  I don't believe we have any sort of 'hostId' 
> today, since hosts just become available by attaching to AMQP.
> 
> - Chris
> 
> On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:
> 
>> I understand that we're all familiar with virtualization and its benefits. 
>> However, in the Real World, those of us who run clouds often need to work 
>> with physical devices. I've proposed a blueprint and spec for a /hosts admin 
>> API resource that would return information on physical hosts. However, I 
>> don't believe that there's any way for us to actually identify a specific 
>> server (I'm actually hoping I'm mistaken about this, because that would make 
>> my life easier). 
>> 
>> So, to get information about a specific host, you'd use /host/{id} — but 
>> what should go in the {id} slot?
>> 
>> We'd also like to include this data elsewhere; for example, in error 
>> messages, it might help to know the physical device on which a server is 
>> created. 
>> 
>> 
>> 
>> This email may include confidential information. If you received it in 
>> error, please delete it.
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 

This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Physical host identification

[Glen Campbell]

I understand that we're all familiar with virtualization and its benefits. 
However, in the Real World, those of us who run clouds often need to work with 
physical devices. I've proposed a blueprint and spec for a /hosts admin API 
resource that would return information on physical hosts. However, I don't 
believe that there's any way for us to actually identify a specific server (I'm 
actually hoping I'm mistaken about this, because that would make my life 
easier).

So, to get information about a specific host, you'd use /host/{id} — but what 
should go in the {id} slot?

We'd also like to include this data elsewhere; for example, in error messages, 
it might help to know the physical device on which a server is created.


[cid:EE757CE3-4A6A-4BB0-842C-849556274E00]
This email may include confidential information. If you received it in error, 
please delete it.
<>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Keystone tenants vs. Nova projects

[andi abes]

Just to clarify - yuriy, what you're describing is very reasonable for an
enterprise system, where you definitely strive to achieve centralized
authentication. I however believe that model is too restrictive for a cloud
service provider. These two worlds are somewhat different.

On Jul 15, 2011, at 15:07, andi abes  wrote:

I guess sfdc disagrees with you - they allow e.g Dell to use a single sign
on to authenticate to their services - as a @dell user, you can login with
the same email/password to internal resources as well as sfdc ones. ( in
case it's not obvious - you also update your password in one location - the
Dell AD directory)

On Jul 15, 2011, at 14:14, Yuriy Taraday  wrote:

Currently there is a basic skeleton for only one backend (identity
store) configuration per Keystone instance. It can be either DB or LDAP (the
latter is almost done).
May be in future we should be somehow able to specify not only tenants but
also an backend for each authentication request.
But I cannot imagine a real use case for that. All identities should be
stored in one place. I doubt that it'll be useful to keep different users
and/or tenants (or roles or whatever) in different stores. There usually is
one single central repository, DB, LDAP or may be some billing system. If we
have two isolated systems, we should consider using two separate auth
services.

Kind regards, Yuriy.


On Fri, Jul 15, 2011 at 21:40, andi abes < 
andi.a...@gmail.com> wrote:

> Yuriy,
>
> a  use-case scenario for keystone would be a service provider servicing
>  large customers with  their own  authentication infrastructure (e.g. LDAP/
> AD etc). Obviously, different tenants  have different instances. To
> authenticate a user, the correct authentication back end must be selected.
>
> In your model, how would a service provide be able to allow delegated
> authentication to different customers?
>
>
> On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday < 
> yorik@gmail.com> wrote:
>
>> I think, there should not be such thing as default tenant.
>> If user does not specify tenant in authentication data, ones token should
>> not be bound to any tenant, and user should have access to resources based
>> on global role assignments.
>> If user specify tenant, one should be either explicitly bound to tenant
>> (probably through UserRoleAssignment model, but it is not the best way) or
>> in some global role. Then one will have access to resources based on global
>> role assignments and tenant role assignments.
>> I'm not sure whether users should be added to a tenant and then to roles
>> in this tenant or we should remove totally direct link between user and
>> tenant, so that user is in tenant if and only if one is in any role in this
>> tenant.
>>
>> Kind regards, Yuriy.
>>
>>
>> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh < 
>> liem_m_ngu...@hp.com> wrote:
>>
>>>  When one creates a user, should a user always have a tenant associated
>>> with her?  If that’s the case, then the “default” tenant is the tenant that
>>> the user is associated with at creation time?  Sorry for responding to the
>>> question with another question, but it is unclear for me from looking at the
>>> model (there is no non-null constraint on the tenant_id fk on the user
>>> table).
>>>
>>> ** **
>>>
>>> Thanks,
>>>
>>> Liem
>>>
>>> ** **
>>>
>>> *From:* openstack-bounces+liem_m_nguyen= 
>>> hp.com@
>>> lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=
>>> hp.com@ lists.launchpad.net] *On Behalf Of *Ziad
>>> Sawalha
>>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>>
>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>> openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  ** **
>>>
>>> In the example I gave below they are not members of any group and have no
>>> roles assigned to them. Should they still be authenticated?
>>>
>>> ** **
>>>
>>> *From: *"Rouault, Jason (Cloud Services)" < 
>>> jason.roua...@hp.com>
>>> *Date: *Thu, 14 Jul 2011 16:25:22 +
>>> *To: *Ziad Sawalha < 
>>> ziad.sawa...@rackspace.com>, Yuriy Taraday < 
>>> yorik@gmail.com>, " 
>>> openstack@lists.launchpad.net" < 
>>> openstack@lists.launchpad.net>
>>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>>
>>> ** **
>>>
>>> A user can specify a tenantID at the time of authentication.  If no
>>> tenantID is specified during authentication, then I would expect the
>>> ‘default’ tenant for the user would apply.  The capabilities of User1 on
>>> TenantA (in this case the default tenant for the user) would be determined
>>> by their role and group assignments within the context of TenantA.  
>>>
>>>  
>>>
>>> Jason
>>>
>>>  
>>>
>>> *From:* Ziad Sawalha [ 
>>> mailto:ziad.sawa...@rackspace.com 
>>> ]
>>>
>>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>>> *To:* Rouault, Jason (Cloud Services); Yuriy T

Re: [Openstack] Keystone tenants vs. Nova projects

[andi abes]

I guess sfdc disagrees with you - they allow e.g Dell to use a single sign
on to authenticate to their services - as a @dell user, you can login with
the same email/password to internal resources as well as sfdc ones. ( in
case it's not obvious - you also update your password in one location - the
Dell AD directory)

On Jul 15, 2011, at 14:14, Yuriy Taraday  wrote:

Currently there is a basic skeleton for only one backend (identity
store) configuration per Keystone instance. It can be either DB or LDAP (the
latter is almost done).
May be in future we should be somehow able to specify not only tenants but
also an backend for each authentication request.
But I cannot imagine a real use case for that. All identities should be
stored in one place. I doubt that it'll be useful to keep different users
and/or tenants (or roles or whatever) in different stores. There usually is
one single central repository, DB, LDAP or may be some billing system. If we
have two isolated systems, we should consider using two separate auth
services.

Kind regards, Yuriy.


On Fri, Jul 15, 2011 at 21:40, andi abes  wrote:

> Yuriy,
>
> a  use-case scenario for keystone would be a service provider servicing
>  large customers with  their own  authentication infrastructure (e.g. LDAP/
> AD etc). Obviously, different tenants  have different instances. To
> authenticate a user, the correct authentication back end must be selected.
>
> In your model, how would a service provide be able to allow delegated
> authentication to different customers?
>
>
> On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday wrote:
>
>> I think, there should not be such thing as default tenant.
>> If user does not specify tenant in authentication data, ones token should
>> not be bound to any tenant, and user should have access to resources based
>> on global role assignments.
>> If user specify tenant, one should be either explicitly bound to tenant
>> (probably through UserRoleAssignment model, but it is not the best way) or
>> in some global role. Then one will have access to resources based on global
>> role assignments and tenant role assignments.
>> I'm not sure whether users should be added to a tenant and then to roles
>> in this tenant or we should remove totally direct link between user and
>> tenant, so that user is in tenant if and only if one is in any role in this
>> tenant.
>>
>> Kind regards, Yuriy.
>>
>>
>> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh wrote:
>>
>>>  When one creates a user, should a user always have a tenant associated
>>> with her?  If that’s the case, then the “default” tenant is the tenant that
>>> the user is associated with at creation time?  Sorry for responding to the
>>> question with another question, but it is unclear for me from looking at the
>>> model (there is no non-null constraint on the tenant_id fk on the user
>>> table).
>>>
>>> ** **
>>>
>>> Thanks,
>>>
>>> Liem
>>>
>>> ** **
>>>
>>> *From:* openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net[mailto:
>>> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf
>>> Of *Ziad Sawalha
>>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>>
>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>> openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  ** **
>>>
>>> In the example I gave below they are not members of any group and have no
>>> roles assigned to them. Should they still be authenticated?
>>>
>>> ** **
>>>
>>> *From: *"Rouault, Jason (Cloud Services)" 
>>> *Date: *Thu, 14 Jul 2011 16:25:22 +
>>> *To: *Ziad Sawalha , Yuriy Taraday <
>>> yorik@gmail.com>, "openstack@lists.launchpad.net" <
>>> openstack@lists.launchpad.net>
>>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>>
>>> ** **
>>>
>>> A user can specify a tenantID at the time of authentication.  If no
>>> tenantID is specified during authentication, then I would expect the
>>> ‘default’ tenant for the user would apply.  The capabilities of User1 on
>>> TenantA (in this case the default tenant for the user) would be determined
>>> by their role and group assignments within the context of TenantA.  
>>>
>>>  
>>>
>>> Jason
>>>
>>>  
>>>
>>> *From:* Ziad Sawalha 
>>> [mailto:ziad.sawa...@rackspace.com]
>>>
>>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>> openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  
>>>
>>> What if:
>>>
>>>  
>>>
>>> -  User1 has TenantA as her default tenant
>>>
>>>  
>>>
>>> Should the service authenticate the user against TenantA? And if so, why?
>>> What does the 'default tenant' grant User1 on TenantA? It's some nebulous,
>>>  implied role…
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> *From: *"Rouault, Jason (Cloud Services)" 
>>> *Date: *Wed, 13 Jul 2011 13:18:44 +
>>> *To: *Ziad Sawal

Re: [Openstack] Keystone tenants vs. Nova projects

[Yuriy Taraday]

Currently there is a basic skeleton for only one backend (identity
store) configuration per Keystone instance. It can be either DB or LDAP (the
latter is almost done).
May be in future we should be somehow able to specify not only tenants but
also an backend for each authentication request.
But I cannot imagine a real use case for that. All identities should be
stored in one place. I doubt that it'll be useful to keep different users
and/or tenants (or roles or whatever) in different stores. There usually is
one single central repository, DB, LDAP or may be some billing system. If we
have two isolated systems, we should consider using two separate auth
services.

Kind regards, Yuriy.


On Fri, Jul 15, 2011 at 21:40, andi abes  wrote:

> Yuriy,
>
> a  use-case scenario for keystone would be a service provider servicing
>  large customers with  their own  authentication infrastructure (e.g. LDAP/
> AD etc). Obviously, different tenants  have different instances. To
> authenticate a user, the correct authentication back end must be selected.
>
> In your model, how would a service provide be able to allow delegated
> authentication to different customers?
>
>
> On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday wrote:
>
>> I think, there should not be such thing as default tenant.
>> If user does not specify tenant in authentication data, ones token should
>> not be bound to any tenant, and user should have access to resources based
>> on global role assignments.
>> If user specify tenant, one should be either explicitly bound to tenant
>> (probably through UserRoleAssignment model, but it is not the best way) or
>> in some global role. Then one will have access to resources based on global
>> role assignments and tenant role assignments.
>> I'm not sure whether users should be added to a tenant and then to roles
>> in this tenant or we should remove totally direct link between user and
>> tenant, so that user is in tenant if and only if one is in any role in this
>> tenant.
>>
>> Kind regards, Yuriy.
>>
>>
>> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh wrote:
>>
>>>  When one creates a user, should a user always have a tenant associated
>>> with her?  If that’s the case, then the “default” tenant is the tenant that
>>> the user is associated with at creation time?  Sorry for responding to the
>>> question with another question, but it is unclear for me from looking at the
>>> model (there is no non-null constraint on the tenant_id fk on the user
>>> table).
>>>
>>> ** **
>>>
>>> Thanks,
>>>
>>> Liem
>>>
>>> ** **
>>>
>>> *From:* openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net[mailto:
>>> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf
>>> Of *Ziad Sawalha
>>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>>
>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>> openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  ** **
>>>
>>> In the example I gave below they are not members of any group and have no
>>> roles assigned to them. Should they still be authenticated?
>>>
>>> ** **
>>>
>>> *From: *"Rouault, Jason (Cloud Services)" 
>>> *Date: *Thu, 14 Jul 2011 16:25:22 +
>>> *To: *Ziad Sawalha , Yuriy Taraday <
>>> yorik@gmail.com>, "openstack@lists.launchpad.net" <
>>> openstack@lists.launchpad.net>
>>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>>
>>> ** **
>>>
>>> A user can specify a tenantID at the time of authentication.  If no
>>> tenantID is specified during authentication, then I would expect the
>>> ‘default’ tenant for the user would apply.  The capabilities of User1 on
>>> TenantA (in this case the default tenant for the user) would be determined
>>> by their role and group assignments within the context of TenantA.  
>>>
>>>  
>>>
>>> Jason
>>>
>>>  
>>>
>>> *From:* Ziad Sawalha 
>>> [mailto:ziad.sawa...@rackspace.com]
>>>
>>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>> openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  
>>>
>>> What if:
>>>
>>>  
>>>
>>> -  User1 has TenantA as her default tenant
>>>
>>>  
>>>
>>> Should the service authenticate the user against TenantA? And if so, why?
>>> What does the 'default tenant' grant User1 on TenantA? It's some nebulous,
>>>  implied role…
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> *From: *"Rouault, Jason (Cloud Services)" 
>>> *Date: *Wed, 13 Jul 2011 13:18:44 +
>>> *To: *Ziad Sawalha , Yuriy Taraday <
>>> yorik@gmail.com>, "openstack@lists.launchpad.net" <
>>> openstack@lists.launchpad.net>
>>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>>
>>>  
>>>
>>> If a user is bound to their default tenant, why wouldn’t any role
>>> assignments for that user in their default tenant apply?
>>>
>>>  
>>>
>>>  
>>

Re: [Openstack] Keystone tenants vs. Nova projects

[andi abes]

Yuriy,

a  use-case scenario for keystone would be a service provider servicing
 large customers with  their own  authentication infrastructure (e.g. LDAP/
AD etc). Obviously, different tenants  have different instances. To
authenticate a user, the correct authentication back end must be selected.

In your model, how would a service provide be able to allow delegated
authentication to different customers?


On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday  wrote:

> I think, there should not be such thing as default tenant.
> If user does not specify tenant in authentication data, ones token should
> not be bound to any tenant, and user should have access to resources based
> on global role assignments.
> If user specify tenant, one should be either explicitly bound to tenant
> (probably through UserRoleAssignment model, but it is not the best way) or
> in some global role. Then one will have access to resources based on global
> role assignments and tenant role assignments.
> I'm not sure whether users should be added to a tenant and then to roles in
> this tenant or we should remove totally direct link between user and tenant,
> so that user is in tenant if and only if one is in any role in this tenant.
>
> Kind regards, Yuriy.
>
>
> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh wrote:
>
>>  When one creates a user, should a user always have a tenant associated
>> with her?  If that’s the case, then the “default” tenant is the tenant that
>> the user is associated with at creation time?  Sorry for responding to the
>> question with another question, but it is unclear for me from looking at the
>> model (there is no non-null constraint on the tenant_id fk on the user
>> table).
>>
>> ** **
>>
>> Thanks,
>>
>> Liem
>>
>> ** **
>>
>> *From:* openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net[mailto:
>> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
>> *Ziad Sawalha
>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>
>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>> openstack@lists.launchpad.net
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>
>>  ** **
>>
>> In the example I gave below they are not members of any group and have no
>> roles assigned to them. Should they still be authenticated?
>>
>> ** **
>>
>> *From: *"Rouault, Jason (Cloud Services)" 
>> *Date: *Thu, 14 Jul 2011 16:25:22 +
>> *To: *Ziad Sawalha , Yuriy Taraday <
>> yorik@gmail.com>, "openstack@lists.launchpad.net" <
>> openstack@lists.launchpad.net>
>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>
>> ** **
>>
>> A user can specify a tenantID at the time of authentication.  If no
>> tenantID is specified during authentication, then I would expect the
>> ‘default’ tenant for the user would apply.  The capabilities of User1 on
>> TenantA (in this case the default tenant for the user) would be determined
>> by their role and group assignments within the context of TenantA.  
>>
>>  
>>
>> Jason
>>
>>  
>>
>> *From:* Ziad Sawalha 
>> [mailto:ziad.sawa...@rackspace.com]
>>
>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>> openstack@lists.launchpad.net
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>
>>  
>>
>> What if:
>>
>>  
>>
>> -  User1 has TenantA as her default tenant
>>
>>  
>>
>> Should the service authenticate the user against TenantA? And if so, why?
>> What does the 'default tenant' grant User1 on TenantA? It's some nebulous,
>>  implied role…
>>
>>  
>>
>>  
>>
>>  
>>
>> *From: *"Rouault, Jason (Cloud Services)" 
>> *Date: *Wed, 13 Jul 2011 13:18:44 +
>> *To: *Ziad Sawalha , Yuriy Taraday <
>> yorik@gmail.com>, "openstack@lists.launchpad.net" <
>> openstack@lists.launchpad.net>
>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>>
>>  
>>
>> If a user is bound to their default tenant, why wouldn’t any role
>> assignments for that user in their default tenant apply?
>>
>>  
>>
>>  
>>
>> User1 authenticates specifying TenantB, this binds User1 into the context
>> of TenantB.  In subsequent web service requests using the token received
>> after authentication, the Auth component filter would decorate the headers
>> with RoleY.
>>
>> If User1 authenticates specifying TenantA, or specifying no Tenant,  this
>> binds User1 into the context of TenantA.  The headers would then be
>> decorated with RoleX.
>>
>>  
>>
>> Jason
>>
>>  
>>
>> *From:* openstack-bounces+jason.rouault=hp@lists.launchpad.net [
>> mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net]
>> *On Behalf Of *Ziad Sawalha
>> *Sent:* Tuesday, July 12, 2011 10:09 PM
>> *To:* Yuriy Taraday; openstack@lists.launchpad.net
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>>
>>  
>>
>> Our goal is to support Nova use cases right now. 

Re: [Openstack] Keystone tenants vs. Nova projects

[Rouault, Jason (Cloud Services)]

In typical RBAC systems you specify the role you will be acting in when you 
gain access.  This is the principal of least privilege.

 

Jason

 

From: Yuriy Taraday [mailto:yorik@gmail.com] 
Sent: Friday, July 15, 2011 11:27 AM
To: Nguyen, Liem Manh
Cc: openstack@lists.launchpad.net; Ziad Sawalha; Rouault, Jason (Cloud Services)
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

 

Yeah, I agree that we should not duplicate user-tenant link this way.

But I cannot understand why should we have anything default. I think, 
everything should be explicit here. It'll make both code and experience simpler 
and clearer.

So, as I said, user will have to have either some global role or some explicit 
connection to tenant through role to authenticate in some tenant.

 

Kind regards, Yuriy.

 

On Fri, Jul 15, 2011 at 20:14, Nguyen, Liem Manh  wrote:

Hi Yuriy,

 

The “dual” link concept between user and tenant (user <-> tenant, and user <-> 
role <-> tenant) is a little bit confusing for me (perhaps, I don’t understand 
the nuances of it).  What happens if a user belongs to a tenant but has no role 
in it?  It seems to me that instead of having a default tenant for a user, we 
should have a default role for a user instead.  With a default role, we can 
always make sure that the user is authenticated.

 

Regards,

Liem

 

From: Yuriy Taraday [mailto:yorik@gmail.com] 
Sent: Thursday, July 14, 2011 10:37 PM


To: openstack@lists.launchpad.net

Cc: Ziad Sawalha; Rouault, Jason (Cloud Services); Nguyen, Liem Manh


Subject: Re: [Openstack] Keystone tenants vs. Nova projects

 

I think, there should not be such thing as default tenant.

If user does not specify tenant in authentication data, ones token should not 
be bound to any tenant, and user should have access to resources based on 
global role assignments.

If user specify tenant, one should be either explicitly bound to tenant 
(probably through UserRoleAssignment model, but it is not the best way) or in 
some global role. Then one will have access to resources based on global role 
assignments and tenant role assignments.

I'm not sure whether users should be added to a tenant and then to roles in 
this tenant or we should remove totally direct link between user and tenant, so 
that user is in tenant if and only if one is in any role in this tenant.


Kind regards, Yuriy.

 

 

On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh  wrote:

When one creates a user, should a user always have a tenant associated with 
her?  If that’s the case, then the “default” tenant is the tenant that the user 
is associated with at creation time?  Sorry for responding to the question with 
another question, but it is unclear for me from looking at the model (there is 
no non-null constraint on the tenant_id fk on the user table).

 

Thanks,

Liem

 

From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net 
[mailto:openstack-bounces+liem_m_nguyen 
 =hp@lists.launchpad.net] On 
Behalf Of Ziad Sawalha
Sent: Thursday, July 14, 2011 12:22 PM


To: Rouault, Jason (Cloud Services); Yuriy Taraday; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

 

In the example I gave below they are not members of any group and have no roles 
assigned to them. Should they still be authenticated?

 

From: "Rouault, Jason (Cloud Services)" 
Date: Thu, 14 Jul 2011 16:25:22 +
To: Ziad Sawalha , Yuriy Taraday 
, "openstack@lists.launchpad.net" 

Subject: RE: [Openstack] Keystone tenants vs. Nova projects

 

A user can specify a tenantID at the time of authentication.  If no tenantID is 
specified during authentication, then I would expect the ‘default’ tenant for 
the user would apply.  The capabilities of User1 on TenantA (in this case the 
default tenant for the user) would be determined by their role and group 
assignments within the context of TenantA.  

 

Jason

 

From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] 
Sent: Wednesday, July 13, 2011 10:35 PM
To: Rouault, Jason (Cloud Services); Yuriy Taraday; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

 

What if:

 

-  User1 has TenantA as her default tenant

 

Should the service authenticate the user against TenantA? And if so, why? What 
does the 'default tenant' grant User1 on TenantA? It's some nebulous,  implied 
role…

 

 

 

From: "Rouault, Jason (Cloud Services)" 
Date: Wed, 13 Jul 2011 13:18:44 +
To: Ziad Sawalha , Yuriy Taraday 
, "openstack@lists.launchpad.net" 

Subject: RE: [Openstack] Keystone tenants vs. Nova projects

 

If a user is bound to their default tenant, why wouldn’t any role assignments 
for that user in their default tenant apply?

 

 

User1 authenticates specifying TenantB, this binds User1 into the context of 
TenantB.  In subsequent web service requests using the token received after 
authentication, the Auth component filter wo

Re: [Openstack] Keystone tenants vs. Nova projects

[Yuriy Taraday]

Yeah, I agree that we should not duplicate user-tenant link this way.
But I cannot understand why should we have anything default. I think,
everything should be explicit here. It'll make both code and
experience simpler and clearer.
So, as I said, user will have to have either some global role or some
explicit connection to tenant through role to authenticate in some tenant.

Kind regards, Yuriy.

On Fri, Jul 15, 2011 at 20:14, Nguyen, Liem Manh wrote:

>  Hi Yuriy,
>
> ** **
>
> The “dual” link concept between user and tenant (user <-> tenant, and user
> <-> role <-> tenant) is a little bit confusing for me (perhaps, I don’t
> understand the nuances of it).  What happens if a user belongs to a tenant
> but has no role in it?  It seems to me that instead of having a default
> tenant for a user, we should have a default *role* for a user instead.
> With a default role, we can always make sure that the user is authenticated.
> 
>
> ** **
>
> Regards,
>
> Liem
>
> ** **
>
> *From:* Yuriy Taraday [mailto:yorik@gmail.com]
> *Sent:* Thursday, July 14, 2011 10:37 PM
>
> *To:* openstack@lists.launchpad.net
> *Cc:* Ziad Sawalha; Rouault, Jason (Cloud Services); Nguyen, Liem Manh
>
> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>
>  ** **
>
> I think, there should not be such thing as default tenant.
>
> If user does not specify tenant in authentication data, ones token should
> not be bound to any tenant, and user should have access to resources based
> on global role assignments.
>
> If user specify tenant, one should be either explicitly bound to tenant
> (probably through UserRoleAssignment model, but it is not the best way) or
> in some global role. Then one will have access to resources based on global
> role assignments and tenant role assignments.
>
> I'm not sure whether users should be added to a tenant and then to roles in
> this tenant or we should remove totally direct link between user and tenant,
> so that user is in tenant if and only if one is in any role in this tenant.
> 
>
> Kind regards, Yuriy.
>
> ** **
>
> ** **
>
> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh 
> wrote:
>
> When one creates a user, should a user always have a tenant associated with
> her?  If that’s the case, then the “default” tenant is the tenant that the
> user is associated with at creation time?  Sorry for responding to the
> question with another question, but it is unclear for me from looking at the
> model (there is no non-null constraint on the tenant_id fk on the user
> table).
>
>  
>
> Thanks,
>
> Liem
>
>  
>
> *From:* openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net[mailto:
> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
> *Ziad Sawalha
> *Sent:* Thursday, July 14, 2011 12:22 PM
>
>
> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
> openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>
>  
>
> In the example I gave below they are not members of any group and have no
> roles assigned to them. Should they still be authenticated?
>
>  
>
> *From: *"Rouault, Jason (Cloud Services)" 
> *Date: *Thu, 14 Jul 2011 16:25:22 +
> *To: *Ziad Sawalha , Yuriy Taraday <
> yorik@gmail.com>, "openstack@lists.launchpad.net" <
> openstack@lists.launchpad.net>
> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>
>  
>
> A user can specify a tenantID at the time of authentication.  If no
> tenantID is specified during authentication, then I would expect the
> ‘default’ tenant for the user would apply.  The capabilities of User1 on
> TenantA (in this case the default tenant for the user) would be determined
> by their role and group assignments within the context of TenantA.  
>
>  
>
> Jason
>
>  
>
> *From:* Ziad Sawalha 
> [mailto:ziad.sawa...@rackspace.com]
>
> *Sent:* Wednesday, July 13, 2011 10:35 PM
> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
> openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects
>
>  
>
> What if:
>
>  
>
> -  User1 has TenantA as her default tenant
>
>  
>
> Should the service authenticate the user against TenantA? And if so, why?
> What does the 'default tenant' grant User1 on TenantA? It's some nebulous,
>  implied role…
>
>  
>
>  
>
>  
>
> *From: *"Rouault, Jason (Cloud Services)" 
> *Date: *Wed, 13 Jul 2011 13:18:44 +
> *To: *Ziad Sawalha , Yuriy Taraday <
> yorik@gmail.com>, "openstack@lists.launchpad.net" <
> openstack@lists.launchpad.net>
> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects
>
>  
>
> If a user is bound to their default tenant, why wouldn’t any role
> assignments for that user in their default tenant apply?
>
>  
>
>  
>
> User1 authenticates specifying TenantB, this binds User1 into the context
> of TenantB.  I

Re: [Openstack] Keystone tenants vs. Nova projects

[Nguyen, Liem Manh]

Hi Yuriy,

The “dual” link concept between user and tenant (user <-> tenant, and user <-> 
role <-> tenant) is a little bit confusing for me (perhaps, I don’t understand 
the nuances of it).  What happens if a user belongs to a tenant but has no role 
in it?  It seems to me that instead of having a default tenant for a user, we 
should have a default role for a user instead.  With a default role, we can 
always make sure that the user is authenticated.

Regards,
Liem

From: Yuriy Taraday [mailto:yorik@gmail.com]
Sent: Thursday, July 14, 2011 10:37 PM
To: openstack@lists.launchpad.net
Cc: Ziad Sawalha; Rouault, Jason (Cloud Services); Nguyen, Liem Manh
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

I think, there should not be such thing as default tenant.
If user does not specify tenant in authentication data, ones token should not 
be bound to any tenant, and user should have access to resources based on 
global role assignments.
If user specify tenant, one should be either explicitly bound to tenant 
(probably through UserRoleAssignment model, but it is not the best way) or in 
some global role. Then one will have access to resources based on global role 
assignments and tenant role assignments.
I'm not sure whether users should be added to a tenant and then to roles in 
this tenant or we should remove totally direct link between user and tenant, so 
that user is in tenant if and only if one is in any role in this tenant.
Kind regards, Yuriy.


On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh 
mailto:liem_m_ngu...@hp.com>> wrote:
When one creates a user, should a user always have a tenant associated with 
her?  If that’s the case, then the “default” tenant is the tenant that the user 
is associated with at creation time?  Sorry for responding to the question with 
another question, but it is unclear for me from looking at the model (there is 
no non-null constraint on the tenant_id fk on the user table).

Thanks,
Liem

From: 
openstack-bounces+liem_m_nguyen=hp.com@lists.launchpad.net
 
[mailto:openstack-bounces+liem_m_nguyen=hp.com@lists.launchpad.net]
 On Behalf Of Ziad Sawalha
Sent: Thursday, July 14, 2011 12:22 PM

To: Rouault, Jason (Cloud Services); Yuriy Taraday; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

In the example I gave below they are not members of any group and have no roles 
assigned to them. Should they still be authenticated?

From: "Rouault, Jason (Cloud Services)" 
mailto:jason.roua...@hp.com>>
Date: Thu, 14 Jul 2011 16:25:22 +
To: Ziad Sawalha 
mailto:ziad.sawa...@rackspace.com>>, Yuriy Taraday 
mailto:yorik@gmail.com>>, 
"openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: RE: [Openstack] Keystone tenants vs. Nova projects

A user can specify a tenantID at the time of authentication.  If no tenantID is 
specified during authentication, then I would expect the ‘default’ tenant for 
the user would apply.  The capabilities of User1 on TenantA (in this case the 
default tenant for the user) would be determined by their role and group 
assignments within the context of TenantA.

Jason

From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com]
Sent: Wednesday, July 13, 2011 10:35 PM
To: Rouault, Jason (Cloud Services); Yuriy Taraday; 
openstack@lists.launchpad.net
Subject: Re: [Openstack] Keystone tenants vs. Nova projects

What if:


-  User1 has TenantA as her default tenant


Should the service authenticate the user against TenantA? And if so, why? What 
does the 'default tenant' grant User1 on TenantA? It's some nebulous,  implied 
role…



From: "Rouault, Jason (Cloud Services)" 
mailto:jason.roua...@hp.com>>
Date: Wed, 13 Jul 2011 13:18:44 +
To: Ziad Sawalha 
mailto:ziad.sawa...@rackspace.com>>, Yuriy Taraday 
mailto:yorik@gmail.com>>, 
"openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: RE: [Openstack] Keystone tenants vs. Nova projects

If a user is bound to their default tenant, why wouldn’t any role assignments 
for that user in their default tenant apply?


User1 authenticates specifying TenantB, this binds User1 into the context of 
TenantB.  In subsequent web service requests using the token received after 
authentication, the Auth component filter would decorate the headers with RoleY.
If User1 authenticates specifying TenantA, or specifying no Tenant,  this binds 
User1 into the context of TenantA.  The headers would then be decorated with 
RoleX.

Jason

From: 
openstack-bounces+jason.rouault=hp@lists.launchpad.net
 [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On 

Re: [Openstack] XEN non-VT based compute workers

[Muriel]

Il 15/07/2011 12:40, Zeeshan Ali Shah ha scritto:

Sound Excellent

I also thought it is  a documentation bug ..

I will try now and will report the experience.

Zeeshan



Hi all,
i'mdoing some testsin thesedays usingxen4.0.2:works fine (except 
withqcow images).

Thanks to thegriddynamicsguysfor makingmy lifeeasierwith theirrepo.

Muriel
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Announcing Ubuntu Cloud Days

[Ahmed Kamal]

Hi everyone,

This is a reminder note that Ubuntu Cloud Days is 10 days away. You can 
read more at:


https://wiki.ubuntu.com/UbuntuCloudDays/
If you would like to host an irc session, please directly edit
https://wiki.ubuntu.com/UbuntuCloudDays/Timetable

For more information or questions, please contact me. Since I'm off next 
week, please also cc "Jorge Castro" 


Regards


On 07/04/2011 05:25 PM, Ahmed Kamal wrote:

Hello everybody,

We're currently planning Ubuntu Cloud Days 
https://wiki.ubuntu.com/UbuntuCloudDays
which will happen from *25th-26th July* (we can expand to handle more 
sessions)


If you use Ubuntu on the cloud or as the cloud and you think you can 
share your experiences with us, I'd love to have you present a session 
at UCD. Please either go and add your session directly to the schedule 
or talk to me about it. Here is the schedule

https://wiki.ubuntu.com/UbuntuCloudDays/Timetable

It's totally ok if you want to present a topic as a team or do a 
hands-on session with a couple of examples.


I appreciate any kind of contribution to UCD, it will be great to show 
the great progress Ubuntu is making in the cloud!


I'm looking forward to this UCD. Thanks for your interest.

Have a great day,
Ahmed


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] FLAG --start_guests_on_host_boot=true

[Leandro Reox]

HI all,

Cant find any reference about this flag on the openstack docs
--start_guests_on_host_boot=true,
is really available ? If so, even if i setted up on hthe compute nova.conf,
doesnt restart instances at node reboot Using Cactus by now Any clues ?
Regards
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-operators] FLAG --start_guests_on_host_boot=true

[Anne Gentle]

Ah, doc bug reporting abounds today. :)

The flag is in /nova/virt/libvirt/connection.py, and it indicates "Whether
to restart guests when the host reboots." It was added prior to revno 989
(it's revno 912) so it should be available in Cactus.

I learned this by grepping the code for part of the flag text, then using
bzr annotate to find the revno for the addition of the flag. You can also
then use bzr log -r912.3.1 to get more info including the date when it was
committed, the person who did the commit, and read their comment.

Hope this helps,
Anne
*Anne Gentle*
a...@openstack.org
 my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
On Fri, Jul 15, 2011 at 9:13 AM, Leandro Reox wrote:

> HI all,
>
> Cant find any reference about this flag on the openstack docs 
> --start_guests_on_host_boot=true,
> is really available ? If so, even if i setted up on hthe compute nova.conf,
> doesnt restart instances at node reboot Using Cactus by now Any clues ?
> Regards
> ___
> Openstack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XEN non-VT based compute workers

[Anne Gentle]

Ah, yes, thank you for pointing it out. Here is the doc bug.

https://bugs.launchpad.net/openstack-manuals/+bug/811027

Anne

* *
*Anne Gentle*

my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 


On Fri, Jul 15, 2011 at 5:36 AM, Soren Hansen  wrote:

> 2011/7/15 Zeeshan Ali Shah :
> > which says "Hardware: OpenStack components are intended to run on
> standard
> > hardware. Specifically for virtualization on the node or nodes running
> > nova-compute, you need a x86 machine with an AMD processor with SVM
> > extensions (also called AMD-V) or an Intel processor with VT
> (virtualization
> > technology) extensions."
>
> Yeah, that's a documentation bug.
>
> With LXC support, we're not even limited to the x86 platform, so this
> is rather out of date.
>
> --
> Soren Hansen| http://linux2go.dk/
> Ubuntu Developer| http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XEN non-VT based compute workers

[Soren Hansen]

2011/7/15 Zeeshan Ali Shah :
> which says "Hardware: OpenStack components are intended to run on standard
> hardware. Specifically for virtualization on the node or nodes running
> nova-compute, you need a x86 machine with an AMD processor with SVM
> extensions (also called AMD-V) or an Intel processor with VT (virtualization
> technology) extensions."

Yeah, that's a documentation bug.

With LXC support, we're not even limited to the x86 platform, so this
is rather out of date.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XEN non-VT based compute workers

[Zeeshan Ali Shah]

Sound Excellent

I also thought it is  a documentation bug ..

I will try now and will report the experience.

Zeeshan


On Fri, Jul 15, 2011 at 12:36 PM, Soren Hansen  wrote:

> 2011/7/15 Zeeshan Ali Shah :
> > which says "Hardware: OpenStack components are intended to run on
> standard
> > hardware. Specifically for virtualization on the node or nodes running
> > nova-compute, you need a x86 machine with an AMD processor with SVM
> > extensions (also called AMD-V) or an Intel processor with VT
> (virtualization
> > technology) extensions."
>
> Yeah, that's a documentation bug.
>
> With LXC support, we're not even limited to the x86 platform, so this
> is rather out of date.
>
> --
> Soren Hansen| http://linux2go.dk/
> Ubuntu Developer| http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>



-- 

-- 
Regards

Zeeshan Ali Shah
System Administrator
PDC-Center for High Performance Computing
CSC School of Computer Science and Communication
KTH-Royal Institute of Technology , Sweden
+46 8 790 9115
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] XEN non-VT based compute workers

[Zeeshan Ali Shah]

>From here i read it
http://docs.openstack.org/cactus/openstack-compute/admin/content/compute-system-requirements.html

which says "*Hardware*: OpenStack components are intended to run on standard
hardware. Specifically for virtualization on the node or nodes running
nova-compute, you need a x86 machine with an AMD processor with SVM
extensions (also called AMD-V) or an Intel processor with VT (virtualization
technology) extensions."


I think It should not be bound to processor type like other Eucalyptus or
Opennebula


Zeeshan

On Tue, Jul 12, 2011 at 2:08 PM, Soren Hansen  wrote:

> 2011/7/12 Zeeshan Ali Shah :
> > Hi,
> > From requirements of nova-compute it seems that it cannot be run on
> non-VT
> > based processors.
>
> Where are you seeing this?
>
> --
> Soren Hansen| http://linux2go.dk/
> Ubuntu Developer| http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>



-- 

-- 
Regards

Zeeshan Ali Shah
System Administrator
PDC-Center for High Performance Computing
CSC School of Computer Science and Communication
KTH-Royal Institute of Technology , Sweden
+46 8 790 9115
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] S3-compatible client tools?

[FUJITA Tomonori]

On Fri, 15 Jul 2011 17:40:28 +1000
Tom Fifield  wrote:

> Hi all,
> 
> Any recommendations for S3-compatible cli or gui client tools to work
> with OpenStack?
> 
> My summary so far:
> * CloudBerry Explorer (windows only!) works
> * S3Fox uses the new sub-domain based buckets, which aren't supported in
> * OpenStack
> * s3cmd should work with the Eucalyptus patches (but I'm failing to get
> * it working now)

The fix for s3cmd hasn't been merged yet. The following branch should
work:

https://code.launchpad.net/~fujita-tomonori/swift/s3-auth


> * s3curl might work
> 
> Thoughts welcome :)
> 
> 
> Regards,
> 
> 
> Tom
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] S3-compatible client tools?

[Tom Fifield]

Hi all,

Any recommendations for S3-compatible cli or gui client tools to work 
with OpenStack?


My summary so far:
* CloudBerry Explorer (windows only!) works
* S3Fox uses the new sub-domain based buckets, which aren't supported in 
OpenStack
* s3cmd should work with the Eucalyptus patches (but I'm failing to get 
it working now)

* s3curl might work

Thoughts welcome :)


Regards,


Tom

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Identity: Keystone API Proposal

[Devin Carlen]

I'm a bit confused as to how Keystone will handle authorization.  It sounds now 
like it is only handling authentication.  Can you clarify?

Devin


On Jul 13, 2011, at 9:41 PM, Ziad Sawalha wrote:

> We've taken much of that out of the current API; so the API does not allow
> creating these entities through the service API.
> 
> And we don't have delegation over tenant administration either, although
> the API we have in place can fully support atier that implements itŠ.
> 
> Z
> 
> On 7/13/11 11:30 AM, "Bryan Taylor"  wrote:
> 
>> How is this different in effect than letting swift or nova be tenants?
>> Each tenant gets to define users, roles, and groups, right?
>> 
>> On 07/13/2011 10:39 AM, Jay Pipes wrote:
>>> On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha
>>>   wrote:
 Here's a possible use case we can implement to address this:
 
 A service 'registers' itself with Keystone and reserves a name (Ex.
 Swift,
 or nova). Keystone will guarantee uniqueness.
 Registered services can then create roles for the service (Ex.
 swift:admin
 or nova:netadmin) or tuples as suggested below (nova:delete:volume)
 On token validation, Keystone returns these roles and a service can
 apply
 it's own policies based on them.
 
 This is super-simplified and we can expand on it.
 Other benefits:
 
 Registration would also be handy to allow services to add and manage
 endpoints as well.
 We can also tie this with the concept of a ClientID so services can
 identify
 themselves as well with a long-lived token
 (see https://github.com/rackspace/keystone/issues/84)
 Common names for services could be implemented as shareable among
 different
 implementations (Ex: compute:admin)
 
 Thoughts?
>>> 
>>> Sounds like a very reasonable approach to me.
>>> 
 And comments inline ZNS>>
>>> 
>>> Hehe, you guys need a better mail client ;)
>>> 
>>> -jay
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> This email may include confidential information. If you received it in
>> error, please delete it.
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> This email may include confidential information. If you received it in error, 
> please delete it.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp