On Tue, Mar 31, 2020 at 05:39:45PM +0200, Andrea Bolognani wrote:
On Thu, 2020-03-26 at 14:33 +0100, Erik Skultety wrote:
> Unlike with the 'test' flavour, where the 'test' user has sudo
> permissions on the system, with machines set up with the 'gitlab'
> flavour which are intended to contact the outside world which, we don't
> want that. More importantly though, we must not use the default root
> password which is set by the install script on such machines.
> Therefore, set the root password to a random one as part of the gitlab
> flavour task, thus only allowing SSH pubkey authentication for the root
> account.
I'm confused by this.
If we want the root account to only be accessible via SSH with a
pubkey, then we can configure sshd accordingly: setting a random
password which is not stored anywhere prevents access not only via
SSH, but also via local access (eg. serial console), which I don't
think is desirable.
I answered this in one of the former patches, so I don't want to repeat it here
too.
Moreover, the root password that is set in the first place is taken
from a mandatory user-provided configuration file, and I'm not sure
we should be condescending towards users by basically saying "we know
you didn't choose a secure password, so we're going to generate a new
one ourselves".
Like I said, with these machines, we need to design them in a way where they
can come and go easily. Once you accept that, you don't care about the root
password as long as you have SSH access via a secure manner (at least I never
cared with the machines I created with virt-builder, or provisioned in beaker).
For personal machines, yes, this is inconvenient, but the sole purpose of these
executors is to live somewhere in the cloud and do 1 job and 1 job only. I'm
planning on proceeding with creating a cloud config for OpenStack for these
machines which is another explanation for the password - for cloud machines,
the root password will always be set by the cloud init script and that one can
either be static, or random (and I have a hunch that the latter is actually
true in production environments where other mechanism are put in use to be able
to get root access, like SSH or a service account with sudo perms).
--
Erik Skultety