Hi! thanks for your comments.
On Wed, Dec 4, 2013 at 4:51 PM, Klaus Aehlig <[email protected]> wrote: > > > I have a few generel comments about this design. It spends quite > some effort to restrict the impact of a compromised master candidate > via RPC, but leaves it with the private root key. Wouldn't a similar > design (each node has its private key, and there is a list of > authorized keys) help here as well? This would also have advantage > of never having to rely on being able to delete a key from node, > in particular if it is offlined to be sent to repair. > I agree with your point that a compromised master candidate could ssh into another master candidate to fetch that nodes' SSL certificate and private key and then issue RPC commands. A bit more background here: - To increase RPC security changing the procedure by generating different client and server certificates and different client certificates for master candidates and normal nodes was anyway necessary, and generating a separate client certificate for each node did not add much more to the complexity and effort of this design. This way the increased security regarding compromised master candidates was just a (cheap and obviously by far not complete) addon and not even in the scope of the original proposal (which talked mostly about compromised normal nodes). - Reducing the ssh keys to master candidates is the first (and cheapest) solution that fixes the demands of the issue 377. I acknowledge that if security of compromised master candidate nodes becomes a higher priority as well (thus going beyond issue 377), it would be desirable to have different ssh pairs for each node as well. I suggest to divide the ssh part of this design in two parts, the first being the one that is already included and an additional part that proposes one ssh key pair per node. I'll send an interdiff soon. Also, I think I should rename the design doc title to mention 'node security' instead of 'master candidate security' since its primary goal was actually more the security of all nodes and not only master candidates. > > Thanks, > Klaus > > > +Objective > > +========= > > + > > +Up till 2.10, Ganeti distributed security-relevant keys to all nodes, > > s/distributed/distributes/ > > You're proposing a new change; it's not implemented yet. > ACK > > > +For offlining, the removal of the keys is particularly important, as the > > +detection of a compromised node might be the very reason for the > offlining. > > Can we rely on the removal working here? What about offlining nodes because > we cannot reach them (network, power supply, etc)? > No, we cannot rely on removal here, but as with many things in Ganeti we try our best as long as it is possible to reach the node. I will however, add this as a remark to the design doc as we cannot promise this to succeed. > > > +- A compromised master candidate would be able to issue RPC requests, > > + but on detection of its compromised state, it can be removed from the > > + cluster (and thus from the candidate map) without the need for > > + redistribution of any certificates, because the other master > candidates > > + can continue using their own certificates. > > I'm not too convinced about the discussion of a compromised master > candidate, > as it still owns the private root key, and hence can steal the client > certificates > from the other master candidates. See my comments above. I'll send an interdiff soon. > Moreover, upon detection of the compromise we > have to assume that it has already done so, so a full renewal of all > credentials > is necessary anyway. > I agree that any sane administrator would issue a full renewal of all credentials anyway, although I was pointing out the increased likelihood if it being necessary (in contrast to the status quo). I will also add a remark here to the design doc to make that point clear. > > > + (TODO: what about WConfD?) > > WConfD will accept requests only via unix domain sockets, so no external > exposure. > Distribution of the changed configuration is done via RPC, so the above > RPC discussion > applies. > Okay, I'll add a paragraph here to make it explicit that the WConfD design does not conflict with this design. Cheers, Helga
