Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On Fri, Feb 21, 2014 at 10:24:24AM +0100, Tomas Sedovic wrote: On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Well if that is the case and we can't change the templates/heat to change that, the secrets should be put in Keystone or at least go through Keystone. Or use Barbican or whatever. We shouldn't be implementing crypto in Tuskar. +1 Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/23/2014 01:16 AM, Clint Byrum wrote: Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Tuskar does not need to reinvent this. Use OS::Heat::RandomString in the templates. If any of them need to be exposed to the user, use an output on the template. If they need to be regenerated, you can pass a salt parameter. Do we actually need to expose to the user something else than AdminPassword? We are using tripleo-heat-templates currently, so we will need to make the change there. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 21/02/14 10:03, Radomir Dopieralski wrote: On 21/02/14 10:38, Dougal Matthews wrote: At the moment we are guessing, we don't even know how many passwords we need to store. So we should progress with the safest and simplest option (which is to not store them) and consider changing this later. I think we have a pretty good idea: https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overcloud/workflows/undeployed_configuration.py#L23-L222 (just count the NoEcho: true lines) Right, that's a good list. There seemed to be guessing in others emails which is what I was referring too. Thanks for the pointer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/24/2014 09:39 AM, Ladislav Smola wrote: On 02/23/2014 01:16 AM, Clint Byrum wrote: Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Tuskar does not need to reinvent this. Use OS::Heat::RandomString in the templates. If any of them need to be exposed to the user, use an output on the template. If they need to be regenerated, you can pass a salt parameter. Do we actually need to expose to the user something else than AdminPassword? I think we should not. The MySQL password or any of the service passwords are implementation details of the cloud, it should not be used by anyone, except for OpenStack internally. The administrator should setup separate user accounts with the proper privileges to access these services. Imre We are using tripleo-heat-templates currently, so we will need to make the change there. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Well if that is the case and we can't change the templates/heat to change that, the secrets should be put in Keystone or at least go through Keystone. Or use Barbican or whatever. We shouldn't be implementing crypto in Tuskar. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 21/02/14 09:24, Tomas Sedovic wrote: On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Well if that is the case and we can't change the templates/heat to change that, the secrets should be put in Keystone or at least go through Keystone. Or use Barbican or whatever. We shouldn't be implementing crypto in Tuskar. +1, after giving this quite a bit of thought i completely agree. This is really out of the scope of Tuskar. I think we should definitely go down this route and only fall back to storing all these details later, that could be an improvement if it turns out to be a real usability problem. At the moment we are guessing, we don't even know how many passwords we need to store. So we should progress with the safest and simplest option (which is to not store them) and consider changing this later. Dougal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 21/02/14 10:38, Dougal Matthews wrote: On 21/02/14 09:24, Tomas Sedovic wrote: On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. I am not sure if all these use cases have different password requirement. If you check devtest, no matter whether you are creating or just updating your overcloud, all the parameters have to be provided for the heat template: https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 I would rather not require the user to enter 5/10/15 different passwords every time Tuskar updates the stack. I think it's much better to autogenerate the passwords for the first time, provide an option to override them, then save and encrypt them in Tuskar. So +1 for designing a proper system for storing the passwords. Well if that is the case and we can't change the templates/heat to change that, the secrets should be put in Keystone or at least go through Keystone. Or use Barbican or whatever. We shouldn't be implementing crypto in Tuskar. +1, after giving this quite a bit of thought i completely agree. This is really out of the scope of Tuskar. I think we should definitely go down this route and only fall back to storing all these details later, that could be an improvement if it turns out to be a real usability problem. At the moment we are guessing, we don't even know how many passwords we need to store. So we should progress with the safest and simplest option (which is to not store them) and consider changing this later. I think we have a pretty good idea: https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overcloud/workflows/undeployed_configuration.py#L23-L222 (just count the NoEcho: true lines) -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 19/02/14 18:29, Dougal Matthews wrote: The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. We will need whatever the Heat template needs to generate all the configuration files. That includes passwords for all services that are going to be configured, such as, for example, Swift or MySQL. I'm not sure about the exact mechanisms in Heat, but I would guess that we will need all the parameters, including passwords, when the templates are re-generated. We could probably generate new passwords every time, though. If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. All the template parameters that are passwords are marked in the Heat parameter list that we get from it as NoEcho: true, so we do have an idea about which parts are sensitive. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/19/2014 06:10 PM, Ladislav Smola wrote: Hello, I would like to have your opinion about how to deal with passwords in Tuskar-API The background is, that tuskarAPI is storing heat template parameters in its database, it's a preparation for more complex workflows, when we will need to store the data before the actual heat stack-create. So right now, the state is unacceptable, we are storing sensitive data(all the heat passwords and keys) in a raw form in the TuskarAPI database. That is wrong right? Right, that is definitely wrong. So is anybody aware of the reasons, why we would need to store the passwords? Storing them for a small amount of time (rather in a session) should be fine, so we can use them for latter init of the stack. Do we need to store them for heat stack-update? Cause heat throws them away. You will need those passwords after Heat finished creating the stack and Tuskar is going to initialize Keystone and register the services. Keystone can't be used for that because a) Tuskar will need the password, not a token, b) Keystone is not yet initialized. Since stack creation is an asynchronous operation, the session might have gone long time ago. So storing it in the session would not work, Tuskar has to store it in a more permanent place. You will also need the password every time a service need reregistered. Eg. user decides to get rid of swift, then changes his mind, but can't undo the operation because the password is gone. If yes, this bug should change to encrypting of the all sensitive data, right? Cause it might be just me, but dealing with sensitive data like this the 8th deadly sin. The second thing is, if users will update their passwords, info in the TuskarAPI will be obsolete and can't be used anyway. I don't think that the user is going to change the password for different services. We should also investigate if the service will work after someone changes its password. I don't see any problem in storing passwords for the overcloud, since Tuskar *is* the management interface. But I agree, we should do it more securely. Imre There is a bug filled for it: https://bugs.launchpad.net/tuskar/+bug/1282066 Thanks for the feedback, seems like the bug is not as straightforward as I thought. Kind Regards, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/20/2014 10:12 AM, Radomir Dopieralski wrote: On 19/02/14 18:29, Dougal Matthews wrote: The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. We will need whatever the Heat template needs to generate all the configuration files. That includes passwords for all services that are going to be configured, such as, for example, Swift or MySQL. I'm not sure about the exact mechanisms in Heat, but I would guess that we will need all the parameters, including passwords, when the templates are re-generated. We could probably generate new passwords every time, though. That is an excellent point. Tuskar will need the passwords every time it needs to regenerate the Heat template (basically when running stack-update). I don't think, changing the password every time would work. If eg. the MySQL password is changed, then os-refresh-config will fail during the db migration scripts because it no longer can access the existing db with the new password. Imre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 09:12, Radomir Dopieralski wrote: If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. All the template parameters that are passwords are marked in the Heat parameter list that we get from it as NoEcho: true, so we do have an idea about which parts are sensitive. Right, that's good to know. I think Ladislav mentioned this to me but it didn't click. If we do store passwords however, I wonder if we are best to encrypt everything to be safe. The overhead shouldn't be that big and it may be better than special casing the NoEcho values. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 11:21, Dougal Matthews wrote: If we do store passwords however, I wonder if we are best to encrypt everything to be safe. The overhead shouldn't be that big and it may be better than special casing the NoEcho values. I think that before we start encrypting everything, we need to ask ourselves the question about system boundaries and about what we are protecting from what. Otherwise we will end up with ridiculous things like encrypting the passwords and storing the decryption key right in the same place. In other words, this has to be designed. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 10:36, Radomir Dopieralski wrote: On 20/02/14 11:21, Dougal Matthews wrote: If we do store passwords however, I wonder if we are best to encrypt everything to be safe. The overhead shouldn't be that big and it may be better than special casing the NoEcho values. I think that before we start encrypting everything, we need to ask ourselves the question about system boundaries and about what we are protecting from what. Otherwise we will end up with ridiculous things like encrypting the passwords and storing the decryption key right in the same place. In other words, this has to be designed. Absolutely. I couldn't agree more and hope I didn't suggest otherwise :) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 12:02, Radomir Dopieralski wrote: On 20/02/14 11:46, Dougal Matthews wrote: On 20/02/14 10:36, Radomir Dopieralski wrote: On 20/02/14 11:21, Dougal Matthews wrote: If we do store passwords however, I wonder if we are best to encrypt everything to be safe. The overhead shouldn't be that big and it may be better than special casing the NoEcho values. I think that before we start encrypting everything, we need to ask ourselves the question about system boundaries and about what we are protecting from what. Otherwise we will end up with ridiculous things like encrypting the passwords and storing the decryption key right in the same place. In other words, this has to be designed. Absolutely. I couldn't agree more and hope I didn't suggest otherwise :) So what is the smallest subsystem (or subsystems) that needs those passwords, and what storage it has access to that other subsystems don't, so we could put the key there? As I see it, the passwords are needed by: * Heat, for generating the templates (may be passed from Tuskar-API), * Tuskar-API, for passing them to Heat and for registering services in Keystone, * Tuskar-UI, if we want to display them to the user on request (do we?), may also be passed from Tuskar-API. What is the storage that Tuskar-API has access to, but other parts don't? I would guess that's the Tuskar database. But that's where the passwords are already stored, so storing the key there doesn't make much sense. Anybody who gets access to Tuskar-API gets the passwords, whether we encrypt them or not. Anybody who doesn't have access to Tuskar-API doesn't get the passwords, whether we encrypt them or not. Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key in their configuration and send it with the request to (re)deploy. Tuskar-API would still need to keep it for the duration of deployment (to register the services at the end), but that's it. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20.2.2014 12:18, Radomir Dopieralski wrote: On 20/02/14 12:02, Radomir Dopieralski wrote: Anybody who gets access to Tuskar-API gets the passwords, whether we encrypt them or not. Anybody who doesn't have access to Tuskar-API doesn't get the passwords, whether we encrypt them or not. Yeah, i think so too. Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key in their configuration and send it with the request to (re)deploy. Tuskar-API would still need to keep it for the duration of deployment (to register the services at the end), but that's it. This would be possible, but it would damage the user experience quite a bit. Afaik other deployment tools solve password storage the same way we do now. Imho keeping the passwords the way we do now is not among the biggest OpenStack security risks. I think we can make the assumption that undercloud will not be publicly accessible, so a potential external attacker would have to first gain network access to the undercloud machines and only then they can start trying to exploit Tuskar API to hand out the passwords. Overcloud services (which are meant to be publicly accessible) have their service passwords accessible in plaintext, e.g. in nova.conf you'll find nova password and neutron password -- i think this is comparatively greater security risk. So if we can come up with a solution where the benefits outweigh the drawbacks and it makes sense in broader view at OpenStack security, we should go for it, but so far i'm not convinced there is such a solution. Just my 2 cents :) Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 10:12, Radomir Dopieralski wrote: On 19/02/14 18:29, Dougal Matthews wrote: The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. We will need whatever the Heat template needs to generate all the configuration files. That includes passwords for all services that are going to be configured, such as, for example, Swift or MySQL. This is a one-time operation, though, isn't it? You pass those parameters to Heat when you run stack-create. Heat and os-*-config will handle the rest. I'm not sure about the exact mechanisms in Heat, but I would guess that we will need all the parameters, including passwords, when the templates are re-generated. We could probably generate new passwords every time, though. What do you mean by regenarating the templates? Do you mean when we want to update the deployment (e.g. using heat stack-update)? If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. All the template parameters that are passwords are marked in the Heat parameter list that we get from it as NoEcho: true, so we do have an idea about which parts are sensitive. If at all possible, we should not store any passwords or keys whatsoever. We may have to pass them through from the user to an API (and then promptly forget them) or possible hold onto them for a little while (in RAM) but never persisting them anywhere. Let's go through the specific cases where we do handle passwords and what to do with them. Looking at devtest, I can see two places where the user deals with passwords: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html 1) in the step 10. (Deploy an overcloud) we pass the various overcloud service passwords and keys to Heat (it's things like the Keystone Admin Token password, SSL key cert, nova/heat/cinder/glance service passwords, etc.). I'm assuming this could include any database and AMQP passwords in the future. 2) step 17 18 (Perform admin setup of your overcloud) where pass some of the same passwords to Keystone to set up the Overcloud OpenStack services (compute, metering, orchestration, etc.) And that's it. I'd love if we could eventually push the steps 17 18 into our Heat templates, it's where they belong I think (please correct me if that's wrong). Regardless, all the passwords here are user-specified. When you install OpenStack, you have to come up with a bunch of passwords up front and use them to set the various services up. Now Tuskar serves as an intermediary. It should ask for these passwords and then perform the steps you'd otherwise do manually and then *forget* the passwords again. Since we're using the passwords in 2 steps (10 and 17), we can't just pass them to Heat and immediately forget them. But we can pass them in step 10, wait for it to finish, pass them to step 17 and forget them then. So here's the workflow: 1. The user wants to deploy the overcloud through the UI 2. They're asked to fill in all the necessary information (including the passwords) -- or we autogenerate it which doesn't change anything 3. Tuskar UI sends a request to Tuskar API including the passwords 3.1. Tuskar UI forgets the passwords (this isn't an explicit action, we don't store them anywhere) 4. Tuskar API fetches/builds the correct Heat template 5. Tuskar API calls heat stack-create and passes in all the params (including passwords) 6. Tuskar API waits for heat stack-create to finish 7. Tuskar API issues a bunch of keystone calls to set up the services (with the specified passwords) 8. Tuskar API forgets the passwords The asynchronous nature of Heat stack-create may make this a bit more difficult but the point should still stand -- we should not persist the passwords. We may have to store them somewhere for a short duration, but not throughout the entire lifecycle of the overcloud. I'm not sure if we have to pass the unchanged parameters to Heat again during stack-update (they may or may not be stored on the metadata server). If we do, I'd vote we ask the user to re-enter them instead of storing them somewhere. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 14:10, Jiří Stránský wrote: On 20.2.2014 12:18, Radomir Dopieralski wrote: On 20/02/14 12:02, Radomir Dopieralski wrote: Anybody who gets access to Tuskar-API gets the passwords, whether we encrypt them or not. Anybody who doesn't have access to Tuskar-API doesn't get the passwords, whether we encrypt them or not. Yeah, i think so too. Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key in their configuration and send it with the request to (re)deploy. Tuskar-API would still need to keep it for the duration of deployment (to register the services at the end), but that's it. This would be possible, but it would damage the user experience quite a bit. Afaik other deployment tools solve password storage the same way we do now. Imho keeping the passwords the way we do now is not among the biggest OpenStack security risks. I think we can make the assumption that undercloud will not be publicly accessible, so a potential external attacker would have to first gain network access to the undercloud machines and only then they can start trying to exploit Tuskar API to hand out the passwords. Overcloud services (which are meant to be publicly accessible) have their service passwords accessible in plaintext, e.g. in nova.conf you'll find nova password and neutron password -- i think this is comparatively greater security risk. This to me reads as: we should fix the OpenStack services not to store passwords in their service.conf, not making the situation worse by storing them in even more places. So if we can come up with a solution where the benefits outweigh the drawbacks and it makes sense in broader view at OpenStack security, we should go for it, but so far i'm not convinced there is such a solution. Just my 2 cents :) Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 14:10, Jiří Stránský wrote: On 20.2.2014 12:18, Radomir Dopieralski wrote: Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key in their configuration and send it with the request to (re)deploy. Tuskar-API would still need to keep it for the duration of deployment (to register the services at the end), but that's it. This would be possible, but it would damage the user experience quite a bit. Afaik other deployment tools solve password storage the same way we do now. I don't think it would damage the user experience so much. All you need is an additional configuration option in Tuskar-UI and Tuskar-client, the encryption key. That key would be used to encrypt the passwords when they are first sent to Tuskar-API, and also added to the (re)deployment calls. This way, if the database leaks due to a security hole in MySQL or bad engineering practices administering the database, the passwords are still inaccessible. To get them, the attacker would need to get *both* the database and the config files from host on which Tuskar-UI runs. With the tuskar-client it's a little bit more obnoxious, because you would need to configure it on every host from which you want to use it, but you already need to do some configuration to point it at the tuskar-api and authenticate it, so it's not so bad. I agree that this complicates the whole process a little, and adds another potential failure point though. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
Just to throw this out there, is this something we need for Icehouse? Yes, I fully acknowledge that it's an ugly security hole. But what's our story for how stable/clean Tuskar will be for Icehouse? I don't believe the intention is for people to use this in a production environment yet, so it will be people trying things out in a test environment. I don't think it's absurd to document that we haven't finished hardening the security yet and to not use super-sensitive passwords. If there was a simple answer, I likely wouldn't even suggest this. But there's some real design and thought that needs to take place and, frankly, we're running out of time. Keeping in mind the intended usage of the Icehouse release of Tuskar, it might make sense to shelve this for now and file a big fat bug that we address in Juno. On 02/20/2014 08:47 AM, Radomir Dopieralski wrote: On 20/02/14 14:10, Jiří Stránský wrote: On 20.2.2014 12:18, Radomir Dopieralski wrote: Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key in their configuration and send it with the request to (re)deploy. Tuskar-API would still need to keep it for the duration of deployment (to register the services at the end), but that's it. This would be possible, but it would damage the user experience quite a bit. Afaik other deployment tools solve password storage the same way we do now. I don't think it would damage the user experience so much. All you need is an additional configuration option in Tuskar-UI and Tuskar-client, the encryption key. That key would be used to encrypt the passwords when they are first sent to Tuskar-API, and also added to the (re)deployment calls. This way, if the database leaks due to a security hole in MySQL or bad engineering practices administering the database, the passwords are still inaccessible. To get them, the attacker would need to get *both* the database and the config files from host on which Tuskar-UI runs. With the tuskar-client it's a little bit more obnoxious, because you would need to configure it on every host from which you want to use it, but you already need to do some configuration to point it at the tuskar-api and authenticate it, so it's not so bad. I agree that this complicates the whole process a little, and adds another potential failure point though. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I'd guess each of these have different password workflow requirements. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 15:57, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I mean clicking scale in tuskar-ui. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 20/02/14 16:02, Radomir Dopieralski wrote: On 20/02/14 15:57, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1. Deploy a brand new overcloud, overwriting the old one 2. Updating the services in the existing overcloud (i.e. image updates) 3. Adding new machines to the existing overcloud 4. Autoscaling 5. Something else 6. All of the above I mean clicking scale in tuskar-ui. Right. So either Heat's able to handle this on its own or we fix it to be able to do that or we ask for the necessary parameters again. I really dislike having to do crypto in tuskar. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 19/02/14 17:10, Ladislav Smola wrote: Hello, I would like to have your opinion about how to deal with passwords in Tuskar-API The background is, that tuskarAPI is storing heat template parameters in its database, it's a preparation for more complex workflows, when we will need to store the data before the actual heat stack-create. So right now, the state is unacceptable, we are storing sensitive data(all the heat passwords and keys) in a raw form in the TuskarAPI database. That is wrong right? I agree, this situation needs to change. I'm +1 for not storing the passwords if we can avoid it. This would apply to all situations and not just Tuskar. The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On Wed 19 Feb 2014 10:29:32 AM MST, Dougal Matthews wrote: On 19/02/14 17:10, Ladislav Smola wrote: Hello, I would like to have your opinion about how to deal with passwords in Tuskar-API The background is, that tuskarAPI is storing heat template parameters in its database, it's a preparation for more complex workflows, when we will need to store the data before the actual heat stack-create. So right now, the state is unacceptable, we are storing sensitive data(all the heat passwords and keys) in a raw form in the TuskarAPI database. That is wrong right? I agree, this situation needs to change. I'm +1 for not storing the passwords if we can avoid it. This would apply to all situations and not just Tuskar. The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Would it be possible to create some token for use throughout? Forgive my naivete. -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 19/02/14 18:29, Jason Rist wrote: Would it be possible to create some token for use throughout? Forgive my naivete. I don't think so, the token would need to be understood by all the services that we store passwords for. I may be misunderstanding however. Dougal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 19/02/14 18:49, Hugh O. Brock wrote: On Wed, Feb 19, 2014 at 06:31:47PM +, Dougal Matthews wrote: On 19/02/14 18:29, Jason Rist wrote: Would it be possible to create some token for use throughout? Forgive my naivete. I don't think so, the token would need to be understood by all the services that we store passwords for. I may be misunderstanding however. Hmm... isn't this approximately what Keystone does? Accept a password once from the user and then return session tokens? Right - but I think the heat template expects passwords, not tokens. I don't know how easily we can change that. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/19/2014 08:05 PM, Dougal Matthews wrote: On 19/02/14 18:49, Hugh O. Brock wrote: On Wed, Feb 19, 2014 at 06:31:47PM +, Dougal Matthews wrote: On 19/02/14 18:29, Jason Rist wrote: Would it be possible to create some token for use throughout? Forgive my naivete. I don't think so, the token would need to be understood by all the services that we store passwords for. I may be misunderstanding however. Hmm... isn't this approximately what Keystone does? Accept a password once from the user and then return session tokens? Right - but I think the heat template expects passwords, not tokens. I don't know how easily we can change that. We most probably can't. Most of the passwords are sent to keystone to setup services. Etc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On 02/19/2014 06:29 PM, Dougal Matthews wrote: On 19/02/14 17:10, Ladislav Smola wrote: Hello, I would like to have your opinion about how to deal with passwords in Tuskar-API The background is, that tuskarAPI is storing heat template parameters in its database, it's a preparation for more complex workflows, when we will need to store the data before the actual heat stack-create. So right now, the state is unacceptable, we are storing sensitive data(all the heat passwords and keys) in a raw form in the TuskarAPI database. That is wrong right? I agree, this situation needs to change. I'm +1 for not storing the passwords if we can avoid it. This would apply to all situations and not just Tuskar. The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. Only password I know about we need right now, is the AdminPassword. Which will be used for first sign in to overcloud Horizon and e.g. CLI. But we should not store that, just display that at some point. If we do need to store passwords it becomes a somewhat thorny issue, how does Tuskar know what a password is? If this is flagged up by the UI/client then we are relying on the user to tell us which isn't wise. This is set on template level by NoEcho attribute. We are already using that information. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
