It should be possible to run the Fuel master node and the slave nodes as a
non-superuser (non-root). Currently, users are required to log into the master
node using the root account by default. This could represent an enterprise
security policy violation for many companies.

This specification addresses usage of the root accounts on slave nodes for user
access.

Many corporate users of Fuel would be required to meet security compliance
standards in their infrastructure including Fuel. Many of such policies
restrict access to non-root accounts. Consequently, Fuel should operate using
non-privileged accounts where it is possible to do so.

There are going to be 2 UNIX user accounts on provisioned nodes to log in as:

User-defined account. This account will be used by operator to log into
provisioned/deployed OpenStack nodes and will be fully configurable by
user via UI (name, password, home directory, sudo settings, SSH keys);
it’s defaults will be:

Name: fueladmin

Password: fueladmin

Home directory: /home/fueladmin

Sudo: ALL=(ALL) ALL (to allow sudo w/ password)

SSH keys: None

Service account. This account is going to be used by Fuel to log into
provisioned/deployed nodes via SSH. It’s going to use key-based SSH
authentication and is going to use the same public key, root is using
now. It’s settings will be hidden from UI and will default to:

Name: fuel

Password: random, generated by Nailgun

Home directory: /var/lib/fuel

Sudo: ALL=(ALL) NOPASSWD: ALL (at this point, service user will have
passwordless sudo; sudo configuration will be made more restrictive
in a separate blueprint in the future)

The accounts will be created at the image building stage (in cloud-config
templates), as well as all the required configuration (sshd, sudoers)

SSH keys will be injected into target images during image build process
by fuel-agent

Every service that uses SSH to access slave nodes will be modified to use
the service account passed by Nailgun for remote login.

CI infrastructure (fuel-qa/fuel-devops) will be updated to use a non-root
account for SSH access to slaves. All the commands that are executed on
slaves and do require elevated privileges will be wrapped into sudo.