Public bug reported:
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.
** Affects: nova
Importance: Undecided
Status: New
** Description changed:
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 are not randomly set when not set by the operator in any way - resulting a
security issue on Windows images 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.
+ 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 a
security issue on Windows images 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.
** Description changed:
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 a
security issue on Windows images 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.
+ 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.
--
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):
New
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
