Re: [PATCH v7 2/4] Jobs based on custom runners: build environment docs and playbook

[Willian Rampazzo]

On Wed, Jun 30, 2021 at 8:28 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Cleber Rosa <crosa@redhat.com> writes:
>
> > To run basic jobs on custom runners, the environment needs to be
> > properly set up.  The most common requirement is having the right
> > packages installed.
> >
> > The playbook introduced here covers the QEMU's project s390x and
> > aarch64 machines.  At the time this is being proposed, those machines
> > have already had this playbook applied to them.
> >
> > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > ---
> >  docs/devel/ci.rst                      |  40 +++++++++
> >  scripts/ci/setup/.gitignore            |   2 +
> >  scripts/ci/setup/build-environment.yml | 116 +++++++++++++++++++++++++
> >  scripts/ci/setup/inventory.template    |   1 +
> >  4 files changed, 159 insertions(+)
> >  create mode 100644 scripts/ci/setup/.gitignore
> >  create mode 100644 scripts/ci/setup/build-environment.yml
> >  create mode 100644 scripts/ci/setup/inventory.template
> >
> > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
> > index 064ffa9988..bfedbb1025 100644
> > --- a/docs/devel/ci.rst
> > +++ b/docs/devel/ci.rst
> > @@ -30,3 +30,43 @@ The GitLab CI jobs definition for the custom runners are 
> > located under::
> >  Custom runners entail custom machines.  To see a list of the machines
> >  currently deployed in the QEMU GitLab CI and their maintainers, please
> >  refer to the QEMU `wiki <https://wiki.qemu.org/AdminContacts>`__.
> > +
> > +Machine Setup Howto
> > +-------------------
> > +
> > +For all Linux based systems, the setup can be mostly automated by the
> > +execution of two Ansible playbooks.  Create an ``inventory`` file
> > +under ``scripts/ci/setup``, such as this::
> > +
> > +  fully.qualified.domain
> > +  other.machine.hostname
> > +
> > +You may need to set some variables in the inventory file itself.  One
> > +very common need is to tell Ansible to use a Python 3 interpreter on
> > +those hosts.  This would look like::
> > +
> > +  fully.qualified.domain ansible_python_interpreter=/usr/bin/python3
> > +  other.machine.hostname ansible_python_interpreter=/usr/bin/python3
>
> I was able to put root@foo for the machines I had in my .ssh/config
>
> > +
> > +Build environment
> > +~~~~~~~~~~~~~~~~~
> > +
> > +The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will
> > +set up machines with the environment needed to perform builds and run
> > +QEMU tests.  This playbook consists on the installation of various
> > +required packages (and a general package update while at it).  It
> > +currently covers a number of different Linux distributions, but it can
> > +be expanded to cover other systems.
> > +
> > +The minimum required version of Ansible successfully tested in this
> > +playbook is 2.8.0 (a version check is embedded within the playbook
> > +itself).  To run the playbook, execute::
> > +
> > +  cd scripts/ci/setup
> > +  ansible-playbook -i inventory build-environment.yml
> > +
> > +Please note that most of the tasks in the playbook require superuser
> > +privileges, such as those from the ``root`` account or those obtained
> > +by ``sudo``.  If necessary, please refer to ``ansible-playbook``
> > +options such as ``--become``, ``--become-method``, ``--become-user``
> > +and ``--ask-become-pass``.
>
> If the above works maybe worth mentioning here because just having root
> ssh is probably the easiest way to manage a box.

If the host is internet-facing, there are lots of recommendations to
disable root access using ssh (eg.
https://www.redhat.com/sysadmin/administering-remote-systems). There
are also recommendations from NIST and SANS.

So, to avoid an unintended creation of an attack vector in the custom
runners, I would personally prefer to let just the ansible tricks in
the documentation than mentioning it is possible (and maybe easier) to
enable root access thru ssh.