- From: Jesse Nelson <
>
- To:
- Subject: [chef] Re: Re: sensitive data best practices
- Date: Wed, 8 Sep 2010 13:05:39 -0700
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=kq+Jggr3ypUgYvlucjeHf0gL4WO0M9Qgddy382HrKxCf03lVSd577Sa4EOBGin2M/r KFUKYn93A7PHYnQv5u/Rg8wEgI7HBe3GdDtRGLkoUFYpwyiFwtvoLmcTZeKX/UU9EZD1 TXZYG0WYnAK/pNLduE8YttF9VkmkF7GQFCXZA=
A "secure" method for storing individual attributes would be slick. Server
already has all clients pub keys. It could use to encrypt and clients can
unwind on their end. Seems like that shouldn't be too hard to implement, but
I am pretty ignorant about the api internals.
This solution would solve not storing cleartext in couch, and over the wire.
I suppose it would have to also replace the strings in the cookbook when
stored. Access to couch and client keys still fundamentally being an issue.
Personally haven't had to solve this problem yet, but i've been thinking
about it a bit for some work on the horizon.
On Sep 8, 2010, at 9:15 AM, Adam Jacob wrote:
>
We've had a couple of different approaches. One is to store secrets
>
in data bags, another is to store it as node attribute data.
>
>
A third alternative would be to encrypt the data yourself, and then
>
deal with key distribution. You can't avoid this - at some point, if
>
you want the data to be both available and secure, you'll have to
>
encrypt it, and you'll have to distribute the keys.
>
>
Adam
>
>
On Mon, Sep 6, 2010 at 7:57 PM, Andrew Shafer
>
<
>
>
wrote:
>
>
>
> How are people sensitive data?
>
> For example 'passwords'... not just passwords for the nodes but for other
>
> services like mysql that are running.
>
> Anyone doing something they think is awesomely secure?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
>
Opscode, Inc.
>
Adam Jacob, CTO
>
T: (206) 508-7449 E:
>
Archive powered by MHonArc 2.6.16.