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

Reply via email to