Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
I think the user resource should not have roles in it. There should be a Role Assignment resource that grants roles to users on either tenants (projects) or domains. On the other hand, the user resource should have a domain association. Also, consider adding support for groups and in the future maybe also federation. As for trusts, I don't think it should be Heat's responsibility to set them up, because it's up to the users themselves to create and grant trusts to their trustees. - Original Message - From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Sent: Tuesday, 3 February, 2015 12:26:41 AM Subject: Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat On 30/01/15 02:19, Thomas Spatzier wrote: From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? I am really not a keystone expert, so don't know what the security implications would be, but I have heard the requirement or wish to be able to create users, roles etc. from a template many times. I've talked to people who want to explore this for onboarding use cases, e.g. for onboarding of lines of business in a company, or for onboarding customers in a public cloud case. They would like to be able to have templates that lay out the overall structure for authentication stuff, and then parameterize it for each onboarding process. If this is something to be enabled, that would be interesting to explore. Thanks for the input everyone. I raised a spec + blueprint here: https://review.openstack.org/152309 I don't have any immediate plans to work on this, so if anybody wants to grab it they'd be more than welcome :) cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On 30/01/15 02:19, Thomas Spatzier wrote: From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? I am really not a keystone expert, so don't know what the security implications would be, but I have heard the requirement or wish to be able to create users, roles etc. from a template many times. I've talked to people who want to explore this for onboarding use cases, e.g. for onboarding of lines of business in a company, or for onboarding customers in a public cloud case. They would like to be able to have templates that lay out the overall structure for authentication stuff, and then parameterize it for each onboarding process. If this is something to be enabled, that would be interesting to explore. Thanks for the input everyone. I raised a spec + blueprint here: https://review.openstack.org/152309 I don't have any immediate plans to work on this, so if anybody wants to grab it they'd be more than welcome :) cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On 01/30/2015 02:19 AM, Thomas Spatzier wrote: From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? I am really not a keystone expert, I am! But when I grow up, I want to be a fireman! so don't know what the security implications would be, but I have heard the requirement or wish to be able to create users, roles etc. from a template many times. SHould be possible. LDAP can be read only, but these things can all go into SQL, and just have a loose coupling with the LDAP entities. I've talked to people who want to explore this for onboarding use cases, e.g. for onboarding of lines of business in a company, or for onboarding customers in a public cloud case. They would like to be able to have templates that lay out the overall structure for authentication stuff, and then parameterize it for each onboarding process. THose domains, users, projects ,etc would all go intop SQL. THe only case ot use LDAP would be if their remote organization already had an LDAP system that contained users, and the4y wanted to reuse it. There are issues, there, and I suspect Federation (SAML) will be the mechanism of choice for these types of integrations, not LDAP. If this is something to be enabled, that would be interesting to explore. Regards, Thomas cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
I was asking earlier this week about keystone resources on the irc channel... We're thinking about having a tenant per user on one of our clouds. We're using neutron. So setting this up involves: * Creating a User * Creating a Tenant * Assigning Roles * Creating the Tenants default Private network. (owned by the tenant) * Creating a Neutron Router. (owned by the tenant) * Setting the Router gateway. * Plugging in the Router to the Private network. * Setting some additional security group rules on the users default group. (Out of the box we want icmp and port 22 open) We'd like to have the heat stack maintained by the admin's tenant so they are protected. I tried but some of this stuff can't be done in heat today. I ended up having to write a shell script. I'd love to be able to use heat for this. Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Thursday, January 29, 2015 8:41 AM To: openstack Development Mailing List Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On Fri, Jan 30, 2015 at 4:20 AM, Steven Hardy sha...@redhat.com wrote: On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote: On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I've not heard of that feature, but it's definitely now possible to configure per-domain backends, so for example you could have the heat domain backed by SQL and other domains containing real human users backed by a read-only directory. http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ Perhaps we need to seek clarification from Adam/Henry, but my understanding of that feature is not that it enables you to add users to domains backed by a read-only directory, but rather that multiple backends are possible, such that one domain can be backed by a read-only backend, and another (different) domain can be backed by a different read/write one. E.g in the example above, you might have the freeipa domain backed by read-only LDAP which contains your directory of human users, and you might also have a different domain e.g services or heat backed by a read/write backend e.g Sql. Steve You might want to think about what can be done using federation. Federation allows keystone to talk to external identity providers, where these identity providers have the users. What if heat was an identity provider? Then heat would have a record of the users and they could be used with keystone to get a token. On a similar note, while keystone isn't going to let you create users in a read-only LDAP backend, heat could talk directly to the LDAP server to create users. - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote: On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I've not heard of that feature, but it's definitely now possible to configure per-domain backends, so for example you could have the heat domain backed by SQL and other domains containing real human users backed by a read-only directory. http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ Perhaps we need to seek clarification from Adam/Henry, but my understanding of that feature is not that it enables you to add users to domains backed by a read-only directory, but rather that multiple backends are possible, such that one domain can be backed by a read-only backend, and another (different) domain can be backed by a different read/write one. E.g in the example above, you might have the freeipa domain backed by read-only LDAP which contains your directory of human users, and you might also have a different domain e.g services or heat backed by a read/write backend e.g Sql. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On 30/01/15 05:20, Steven Hardy wrote: On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote: On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I've not heard of that feature, but it's definitely now possible to configure per-domain backends, so for example you could have the heat domain backed by SQL and other domains containing real human users backed by a read-only directory. http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ Perhaps we need to seek clarification from Adam/Henry, but my understanding of that feature is not that it enables you to add users to domains backed by a read-only directory, but rather that multiple backends are possible, such that one domain can be backed by a read-only backend, and another (different) domain can be backed by a different read/write one. E.g in the example above, you might have the freeipa domain backed by read-only LDAP which contains your directory of human users, and you might also have a different domain e.g services or heat backed by a read/write backend e.g Sql. Ah, you're right, I've been misinterpreting that post this whole time. Thanks! - ZB __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. Note that AWS::IAM::User actually creates a stack domain user[1], e.g a special user inside the heat domain, intended to be used primarily for association with an ec2-keypair (e.g AWS::IAM::AccessKey) so we can do signed requests via the CFN API from inside instances etc. So it's not really creating normal keystone users, but Angus and I have already discused the idea of a native equivalent to this, due to the fact that all StackUser (engine/stack_user.py) subclasses effectively create a hidden resource which is a keystone user in the heat domain. I'd definitely support adding a native OS::Heat::StackUser resource, effectively exposing the stack_user.py code as a resource, and adding optional user properties to all existing StackUser subclasses (e.g all SignalResponders like ScalingPolicy and SoftwareDeployment). This would make the creation of the user for signal auth more transparent, and enable template authors to choose if they want a single user associated with multiple resources (vs now when we force them to have different users for every SignalResponder). [1] http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-2-stack.html IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I've not heard of that feature, but it's definitely now possible to configure per-domain backends, so for example you could have the heat domain backed by SQL and other domains containing real human users backed by a read-only directory. I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. If the requirement is more to enable admins to create any users/roles/projects in templates rather than the heat domain specifically, I'd personally have no problem with e.g OS::Keystone::User provided it was in contrib (as it's going to be admin-only with the default keystone policies). Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I've not heard of that feature, but it's definitely now possible to configure per-domain backends, so for example you could have the heat domain backed by SQL and other domains containing real human users backed by a read-only directory. http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
Excerpts from Zane Bitter's message of 2015-01-29 08:41:36 -0800: I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think you got that a little backward. Keystone lets you have domains that are read/write, and domains that are read-only. So you can have the real users in LDAP and then give a different class of user their own keystone-only domain that they can control. That is a bit confusing to the real functionality gap, which I think is a corner case but worth exploring. Being able to create a user in a domain that the user provides credentials for is a useful thing. A user may want to deploy their own instance control mechanism (like standalone Heat!) for instance, and having a limited-access user for this created by a domain admin with credentials that are only ever stored in Heat seems like a win. Some care is needed to make sure the role can't just 'stack show' on Heat and grab the admin creds, but that seems like something that would go in a deployer guide.. something like Make sure domain admins know not to give delegated users the 'heat-user' role. I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. I feel like admin-only things will matter as soon as real multi-cloud support exists in Heat. What I really want is to have a Heat in my management cloud that reaches into my managed cloud when necessary. Right now in TripleO we have to keep anything admin-only out of the Heat templates and run the utilities from os-cloud-config somewhere because we don't want admin credentials (even just trusts) in Heat. But if we could use the deployment(under) cloud's Heat to reach into the user(over) cloud to add users, roles, networks, etc., then that would maintain the separation our security auditors desire. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat
From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need not be an admin to create users then I think it would be a really useful thing to expose in Heat. Does anyone know if that's the case? I think roles and tenants are likely to remain admin-only, but we have precedent for including resources like that in /contrib... this seems like it would be comparably useful. Thoughts? I am really not a keystone expert, so don't know what the security implications would be, but I have heard the requirement or wish to be able to create users, roles etc. from a template many times. I've talked to people who want to explore this for onboarding use cases, e.g. for onboarding of lines of business in a company, or for onboarding customers in a public cloud case. They would like to be able to have templates that lay out the overall structure for authentication stuff, and then parameterize it for each onboarding process. If this is something to be enabled, that would be interesting to explore. Regards, Thomas cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
