Revision 992fd37d

b/doc/security.rst
33 33 
- Communication between nodes is encrypted using SSL/TLS. A common key
34 34 
  and certificate combo is shared between all nodes of the cluster.  At
35 35 
  this time, no CA is used.
36 
- The Ganeti node daemon will accept RPC requests from any host within
37 
  the cluster with the correct certificate, and the operations it will
36 
- The Ganeti node daemon will accept RPC requests from any host that is
37 
  master candidate within the cluster, and the operations it will
38 38 
  do as a result of these requests are:
39 39 

  		





  40
  40
  
    
  - running commands under the ``/etc/ganeti/hooks`` directory


  		





  ......




  42
  42
  
    
  - overwrite a defined list of files on the host


  		





  43
  43
  
    

  		





  44
  44
  
    
As you can see, as soon as a node is joined, it becomes equal to all


  		





  45
  
  
    
other nodes in the cluster, and the security of the cluster is


  		





  
  45
  
    
other nodes in the cluster wrt to SSH and equal to all non-master


  		





  
  46
  
    
candidate nodes wrt to RPC, and the security of the cluster is


  		





  46
  47
  
    
determined by the weakest node.


  		





  47
  48
  
    

  		





  48
  49
  
    
Note that only the SSH key will allow other machines to run any command


  		





  ......




  100
  101
  
    
the cluster-wide shared SSH key.


  		





  101
  102
  
    

  		





  102
  103
  
    
RPC communication between the master and nodes is protected using


  		





  103
  
  
    
SSL/TLS encryption. Both the client and the server must have the


  		





  104
  
  
    
cluster-wide shared SSL/TLS certificate and verify it when establishing


  		





  105
  
  
    
the connection by comparing fingerprints. We decided not to use a CA to


  		





  106
  
  
    
simplify the key handling.


  		





  
  104
  
    
SSL/TLS encryption. The server must have must have the cluster-wide


  		





  
  105
  
    
shared SSL/TLS certificate. When acting as a client, the nodes use an


  		





  
  106
  
    
individual SSL/TLS certificate. On incoming requests, the server checks


  		





  
  107
  
    
whether the client's certificate is that of a master candidate by


  		





  
  108
  
    
verifying its finterprint to a list of known master candidate


  		





  
  109
  
    
certificates. We decided not to use a CA (yet) to simplify the key


  		





  
  110
  
    
handling.


  		





  107
  111
  
    

  		





  108
  112
  
    
The DRBD traffic is not protected by encryption, as DRBD does not


  		





  109
  113
  
    
support this. It's therefore recommended to implement host-level


  		












Also available in:
  Unified diff