Nitpicks, else LGTM. On Fri, Jan 29, 2016 at 1:07 PM, 'Helga Velroyen' via ganeti-devel < [email protected]> wrote:
> This patch updates the design doc of Ganeti's node > security. It turned out that the solution of freezing > master capability is not feasible. This patch explains > the reasons and the alternative considered. > > Signed-off-by: Helga Velroyen <[email protected]> > --- > doc/design-node-security.rst | 55 > +++++++++++--------------------------------- > 1 file changed, 13 insertions(+), 42 deletions(-) > > diff --git a/doc/design-node-security.rst b/doc/design-node-security.rst > index 1215277..84eed0b 100644 > --- a/doc/design-node-security.rst > +++ b/doc/design-node-security.rst > @@ -129,48 +129,19 @@ a particular machine that he is aming for). This > means that with RAPI > access and a compromised normal node, one can make this node a master > candidate and then still have the power to compromise the whole cluster. > > -To mitigate this issue, we propose the following changes: > - > -- Add a flag ``master_capability_rapi_modifiable`` to the cluster > - configuration which indicates whether or not it should be possible > - to modify the ``master_capable`` flag of nodes via RAPI. The flag is > - set to ``False`` by default and can itself only be changed on the > - commandline. In this design doc, we refer to the flag as the > - "rapi flag" from here on. > -- Only if the ``master_capabability_rapi_modifiable`` switch is set to > - ``True``, it is possible to modify the master-capability flag of > - nodes. > - > -With this setup, there are the following definitions of "potential > -master candidates" depending on the rapi flag: > - > -- If the rapi flag is set to ``True``, all cluster nodes are potential > - master candidates, because as described above, all of them can > - eventually be made master candidates via RAPI and thus security-wise, > - we haven't won anything above the current SSH handling. > -- If the rapi flag is set to ``False``, only the master capable nodes > - are considered potential master candidates, as it is not possible to > - make them master candidates via RAPI at all. > - > -Note that when the rapi flag is changed, the state of the > -``ganeti_pub_keys`` file on all nodes has to be updated accordingly. > -This should be done in the client script ``gnt_cluster`` before the > -RPC call to update the configuration is made, because this way, if > -someone would try to perform that RPC call on master to trick it into > -thinking that the flag is enabled, this would not help as the content of > -the ``ganeti_pub_keys`` file is a crucial part in the design of the > -distribution of the SSH keys. > - > -Note: One could think of always allowing to disable the master-capability > -via RAPI and just restrict the enabling of it, thus making it possible > -to RAPI-"freeze" the nodes' master-capability state once it disabled. > -However, we think these are rather confusing semantics of the involved > -flags and thus we go with proposed design. > - > -Note that this change will break RAPI compatibility, at least if the > -rapi flag is not explicitely set to ``True``. We made this choice to > -have the more secure option as default, because otherwise it is > -unlikely to be widely used. > +Various options have been explored to mitigate this, with currently > +no feasible solution to it. We generally advise to not expose RAPI to > with no feasible solution so far. Our general advice is to ... > +the internet and to use authentication. > the Internet. Would it be better to reference the security.html page here? ", as described in the Ganeti security document." > + > +Alternatively, there was the idea of adding a flag to the cluster config > +that would 'freeze' the ``master_capable`` state of nodes. This turned +out to be infeasible, as promoting a node from not ``master_capable`` > +to ``master_capable`` would mean to add the nodes's key to the > +``ganeti_pub_keys`` file. Due to security reasons, this needed to be > +done in the client (similar to when adding a node). That would have > +meant that it would no longer be possible to set this flag via RAPI. As > +setting this flag via RAPI is a feature our users depend on and that > +has been available in the past, we refrain from breaking this feature. > > > Cluster initialization > -- > 2.7.0.rc3.207.g0ac5344 > > Hrvoje Ribicic Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.
