[lxc-devel] Predictable root passwords in LXC templates

[Major Hayden]

On 06/18/2015 01:20 PM, Stéphane Graber wrote:
> I think ideally, I'd like for:
> 
>  - All templates to default to no password at all (no an empty password)
>  - All templates to support a common set of environment variables or/and
>    arguments to have passwords generated for them or to use passwords
>    provided by the user
>  - Have a way (possibly optional) for those credentials to be written
>    down into a text file in the container's directory (for use by scripts).
>  - Print a generic message to the user, advising them of any credential
>    that was generated and that they can use lxc-attach to interact with the
>    container without them.
> 
> I'd also strongly recommend that this happens at the same time as we
> remove sshd by default from all templates, so our containers don't have
> any remote exposure by default (outside of the dhcp client).

I'm totally on board with your ideal solution.  I've taken an inventory of the current templates and there's some wide variance currently:

  https://fedoraproject.org/wiki/LXC_Template_Security_Improvements

The tough thing to work around is that some of the images do different things with user accounts.  For example, Fedora and CentOS have a root user with a random password or the user can specify a password.  Ubuntu makes a user called 'ubuntu', gives it sudo privileges, and sets a 'ubuntu' as the password unless the user specifies otherwise.  Most of the others pick a standard root password and don't allow a user to change it during build. :/

I'll try to hack together a shared script for the templates to use for handling regular user adds, password for those users, and passwords for root.  Part of me wonders if we could leverage something like cloud-init to take care of these changes during first boot.  That would mean wedging cloud-init (and its string of dependencies) into each container, which seems to bloat up the container a fair amount.

Could we keep the sshd removal separate from the credentials work?  I'd argue that if we have credentials set in a secure way, enabling sshd (so long as it's up to date) would be less of an issue.

--
Major Hayden