Public bug reported:
**Problem Description**
The systems I manage are subjected to specific security-hardening guidance that
causes unwanted alerts for the default-user created by cloud init.
Specifically, because cloud-init creates the default-user with a userid in the
non "system" uid-range, the security-hardening validators expect that the
default-user created by cloud-init will have password-aging attributes set. As
the default-user account acts as a "break-glass" maintenance account, having
password-aging is not generally not desirable.
While cloud-init provides the `system` parameter as a seeming out for
this, using this parameter results in an account with no ${HOME} and, by
extension, no ${HOME}/.ssh/authorized keys ...breaking the ability to
configure the default-user account for key-based logins.
Tried using the `no_create_home` parameter and setting its value to
`false` in hopes of overriding the `system` parameter's default
behavior, but it seems like when `system` is set, `no_create_home` is
wholly ignored.
I could probably use the `uid` parameter instead of the `system`
parameter, but I fear that if I set a value like '500', I may cause
problems for applications whose installers expect to be able to create a
service-account with the same uid ('500' being an example value rather
than a specific value).
**Cloud Provider**
AWS
**Version Info**
cloud-init 18.5 from RHEL/CentOS 7 cloud-init-18.5-3 RPM
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1864728
Title:
Unable to create interactive "system" user
Status in cloud-init:
New
Bug description:
**Problem Description**
The systems I manage are subjected to specific security-hardening guidance
that causes unwanted alerts for the default-user created by cloud init.
Specifically, because cloud-init creates the default-user with a userid in the
non "system" uid-range, the security-hardening validators expect that the
default-user created by cloud-init will have password-aging attributes set. As
the default-user account acts as a "break-glass" maintenance account, having
password-aging is not generally not desirable.
While cloud-init provides the `system` parameter as a seeming out for
this, using this parameter results in an account with no ${HOME} and,
by extension, no ${HOME}/.ssh/authorized keys ...breaking the ability
to configure the default-user account for key-based logins.
Tried using the `no_create_home` parameter and setting its value to
`false` in hopes of overriding the `system` parameter's default
behavior, but it seems like when `system` is set, `no_create_home` is
wholly ignored.
I could probably use the `uid` parameter instead of the `system`
parameter, but I fear that if I set a value like '500', I may cause
problems for applications whose installers expect to be able to create
a service-account with the same uid ('500' being an example value
rather than a specific value).
**Cloud Provider**
AWS
**Version Info**
cloud-init 18.5 from RHEL/CentOS 7 cloud-init-18.5-3 RPM
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1864728/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
