Open Stack

On 11/23/2015 06:03 AM, Daniel P. Berrange wrote:
> On Fri, Nov 20, 2015 at 02:44:17PM -0500, Ben Swartzlander wrote:
>> On 11/20/2015 01:19 PM, Daniel P. Berrange wrote:
>>> On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
>>>> Brick does not have to take over the decisions in order to be a useful
>>>> repository for the code. The motivation for this work is to avoid having
>>>> the dm setup code copied wholesale into cinder, where it becomes difficult
>>>> to keep in sync with the code in nova.
>>>>
>>>> Cinder needs a copy of this code since it is on the data path for certain
>>>> operations (create from image, copy to image, backup/restore, migrate).
>>>
>>> A core goal of using volume encryption in Nova to provide protection for
>>> tenant data, from a malicious storage service. ie if the decryption key
>>> is only ever used by Nova on the compute node, then cinder only ever sees
>>> ciphertext, never plaintext.  Thus if cinder is compromised, then it can
>>> not compromise any data stored in any encrypted volumes.
>>
>> There is a difference between the cinder service and the storage controller
>> (or software system) that cinder manages. You can give the decryption keys
>> to the cinder service without allowing the storage controller to see any
>> plaintext.
>>
>> As Walt says in the relevant patch [1], expecting cinder to do data
>> management without ever performing I/O is unrealistic. The scenario where
>> the compute admin doesn't trust the storage admin is understandable
>> (although less important than other potential types of attacks IMO) but the
>> scenario where the guy managing nova doesn't trust the guy managing cinder
>> makes no sense at all.
>
> So you are implicitly saying here that the cinder admin is different from
> the storage admin. While that certainly may often be true, I strugle to
> categorically say it is always going to be true.

No! I'm saying that while the cinder admin and the storage admin MAY be 
different people, that the cinder admin and the nova admin are ALWAYS 
the same people. In some cases all 3 are the same, but it strains 
credulity to suggest that clouds exist where cinder and nova are run by 
people who don't trust eachother.

Consider the scenario where Alice administers the cloud (nova and 
cinder) but Bob is the storage admin. Alice may use some storage 
controllers provided by Bob and she may not trust him. In that case she 
can arrange for nova and cinder to have access to the encryption keys, 
while never allowing Bob to have them. As long as encryption/decryption 
happen on an OpenStack node and not the storage controller itself, Bob 
will never see plaintext.

If Alice and Bob are the same person (which would be true in small 
deployments), then the problem vanishes because there are no 
untrustworthy people.

> Furthermore it is not only about the trust of the cinder administrator,
> but rather trust of the integrity of the cinder service. OpenStack has
> a great many components that are open to attack, and it is prudent to
> design the system such that successfull security attacks are confined
> to as large a degree as possible. From this POV I think it is entirely
> reasonable & indeed sensible for Nova to have minimal trust of Cinder
> as a whole when it comes to tenant data security.

This is true. Ideally the keys would not need to be in two places. 
However the world we live in is not ideal and it seems unavoidable that 
both nova and cinder will need access to encryption keys unless a 
significant amount of data management code moves from cinder into nova. 
I suggest that the right away to protect against the above (legitimate) 
concern is to harden the cinder node as you would your nova nodes.

> Regards,
> Daniel
>