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 liem_m_ngu...@hp.comwrote: 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) 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.comziad.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) jason.roua...@hp.com *Date: *Wed, 13 Jul 2011 13:18:44 + *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 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.netopenstack-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. You can provide access to multiple tenants using a role assignment (assigning a user a role on a specific tenant effectively binds them to that tenant). However, this raises the issue of what the 'implied' role of a user is when they are bound to their *default* tenant. So we're considering how to alter the model to clean that up. No great solution yet. Any suggestions are welcome…. Ziad *From: *Yuriy Taraday yorik@gmail.com *Date: *Tue, 28 Jun 2011 16:59:08 +0400 *To: *openstack@lists.launchpad.net
Re: [Openstack] XEN non-VT based compute workers
2011/7/15 Zeeshan Ali Shah zas...@pdc.kth.se: 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
Ah, yes, thank you for pointing it out. Here is the doc bug. https://bugs.launchpad.net/openstack-manuals/+bug/811027 Anne * * *Anne Gentle* http://www.facebook.com/conversationandcommunity my blog http://justwriteclick.com/ | my bookhttp://xmlpress.net/publications/conversation-community/| LinkedIn http://www.linkedin.com/in/annegentle | Delicioushttp://del.icio.us/annegentle| Twitter http://twitter.com/annegentle On Fri, Jul 15, 2011 at 5:36 AM, Soren Hansen so...@linux2go.dk wrote: 2011/7/15 Zeeshan Ali Shah zas...@pdc.kth.se: 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] [Openstack-operators] FLAG --start_guests_on_host_boot=true
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 http://justwriteclick.com/ | my bookhttp://xmlpress.net/publications/conversation-community/| LinkedIn http://www.linkedin.com/in/annegentle | Delicioushttp://del.icio.us/annegentle| Twitter http://twitter.com/annegentle On Fri, Jul 15, 2011 at 9:13 AM, Leandro Reox leandro.r...@gmail.comwrote: 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
[Openstack] FLAG --start_guests_on_host_boot=true
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
[Openstack] Announcing Ubuntu Cloud Days
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 jorge AT ubuntu.com 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
Re: [Openstack] XEN non-VT based compute workers
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
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 liem_m_ngu...@hp.comwrote: 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 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@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) 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.comziad.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) jason.roua...@hp.com *Date: *Wed, 13 Jul 2011 13:18:44 + *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 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
Re: [Openstack] Keystone tenants vs. Nova projects
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 liem_m_ngu...@hp.com 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 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@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen mailto:openstack-bounces%2Bliem_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) 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 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) jason.roua...@hp.com Date: Wed, 13 Jul 2011 13:18:44 + 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 If a user is bound to their default tenant, why wouldn’t any role assignments for that user in their default tenant
Re: [Openstack] Keystone tenants vs. Nova projects
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.comwrote: 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) 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.comziad.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) jason.roua...@hp.com *Date: *Wed, 13 Jul 2011 13:18:44 + *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 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.netopenstack-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. You can provide access to multiple tenants using a role
Re: [Openstack] Keystone tenants vs. Nova projects
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.comwrote: 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.comwrote: 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) 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.comziad.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) jason.roua...@hp.com *Date: *Wed, 13 Jul 2011 13:18:44 + *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 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,
Re: [Openstack] Keystone tenants vs. Nova projects
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.comwrote: 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.comwrote: 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) 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.comziad.sawa...@rackspace.comziad.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) jason.roua...@hp.com *Date: *Wed, 13 Jul 2011 13:18:44 + *To: *Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net
Re: [Openstack] Keystone tenants vs. Nova projects
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 andi.a...@gmail.com 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 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 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 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= http://hp.comhp.com@http://lists.launchpad.net lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=http://hp.com hp.com@ http://lists.launchpad.netlists.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.netopenstack@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 jason.roua...@hp.com *Date: *Thu, 14 Jul 2011 16:25:22 + *To: *Ziad Sawalha ziad.sawa...@rackspace.com ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net 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 [ ziad.sawa...@rackspace.com mailto:ziad.sawa...@rackspace.com ziad.sawa...@rackspace.comziad.sawa...@rackspace.com] *Sent:* Wednesday, July 13,
[Openstack] Physical host identification
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.
inline: signature[4].png___
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
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.
signature[4].png
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
On Fri, Jul 15, 2011 at 11:31 PM, Chris Behrens chris.behr...@rackspace.com
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.
signature[4].png
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 http://eg.linkedin.com/pub/karim-allah-ahmed/13/829/550/
___
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
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 chris.behr...@rackspace.com
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.
signature[4].png
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
