[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]
** Changed in: nova
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1942709
Title:
Nova Doesn't Set Instance Passwords
Status in OpenStack Compute (nova):
Expired
Bug description:
I've filed bugs against two deployment stacks regarding
this(https://bugs.launchpad.net/charm-nova-compute/+bug/1933057 and
https://bugs.launchpad.net/kolla-ansible/+bug/1942654), and it was suggested
that i file here as well since this appears unrelated to the manner in which
openstack is deployed.
Using the various deployment mechanisms, i've found that in Wallaby with
libvirt+kvm compute services and OVN networking, instance passwords are never
set. Passwords can not be set by setting them in Horizon, in the CLI, nor are
they randomly set when not set by the operator in any way - resulting in a
security issue on Windows images (and others) which have default passwords
baked in under the expectation that they will be reset by cloud-init at the
first boot to something other than the well known default of the image
(https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password).
The instance metadata password URI is always empty. Userdata however can be
used to set passwords at boot time, though this requires manual intervention to
create the relevant userdata by the operator which still leaves that hard coded
password vuln in play.
Current openstack deployment is Kolla-Ansible 12.2, but this happened with
the Juju stack as well, so its probably a Wallaby (or prior recent release)
issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1942709/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
