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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev