Thanks for the LGTM, FYI the interdiff: diff --git a/doc/design-node-security.rst b/doc/design-node-security.rst index 84eed0b..f4f10aa 100644 --- a/doc/design-node-security.rst +++ b/doc/design-node-security.rst @@ -129,9 +129,9 @@ 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.
-Various options have been explored to mitigate this, with currently -no feasible solution to it. We generally advise to not expose RAPI to -the internet and to use authentication. +Various options have been explored to mitigate this, with no feasible +solution so far. We generally advise to not expose RAPI to the Internet. +For more details on making Ganeti secure, see :doc:`security`. Alternatively, there was the idea of adding a flag to the cluster config that would 'freeze' the ``master_capable`` state of nodes. This turned On Wed, 3 Feb 2016 at 14:10 Hrvoje Ribicic <[email protected]> wrote: > 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. > > -- Helga Velroyen Software Engineer [email protected] Google Germany GmbH Erika-Mann-Strasse 33 80636 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.
