-
Mark Goddard authored
In Kolla Ansible OpenStack deployments, by default, libvirt is configured to allow read-write access via an unauthenticated, unencrypted TCP connection, using the internal API network. This is to facilitate migration between hosts. By default, Kolla Ansible does not use encryption for services on the internal network (and did not support it until Ussuri). However, most other services on the internal network are at least authenticated (usually via passwords), ensuring that they cannot be used by anyone with access to the network, unless they have credentials. The main issue here is the lack of authentication. Any client with access to the internal network is able to connect to the libvirt TCP port and make arbitrary changes to the hypervisor. This could include starting a VM, modifying an existing VM, etc. Given the flexibility of the domain options, it could be seen as equivalent to having root access to the hypervisor. Kolla Ansible supports libvirt TLS [1] since the Train release, using client and server certificates for mutual authentication and encryption. However, this feature is not enabled by default, and requires certificates to be generated for each compute host. This change adds support for libvirt SASL authentication, and enables it by default. This provides base level of security. Deployments requiring further security should use libvirt TLS. [1] https://docs.openstack.org/kolla-ansible/latest/reference/compute/libvirt-guide.html#libvirt-tls Depends-On: https://review.opendev.org/c/openstack/kolla/+/833021 Closes-Bug: #1964013 Change-Id: Ia91ceeb609e4cdb144433122b443028c0278b71e
Mark Goddard authoredIn Kolla Ansible OpenStack deployments, by default, libvirt is configured to allow read-write access via an unauthenticated, unencrypted TCP connection, using the internal API network. This is to facilitate migration between hosts. By default, Kolla Ansible does not use encryption for services on the internal network (and did not support it until Ussuri). However, most other services on the internal network are at least authenticated (usually via passwords), ensuring that they cannot be used by anyone with access to the network, unless they have credentials. The main issue here is the lack of authentication. Any client with access to the internal network is able to connect to the libvirt TCP port and make arbitrary changes to the hypervisor. This could include starting a VM, modifying an existing VM, etc. Given the flexibility of the domain options, it could be seen as equivalent to having root access to the hypervisor. Kolla Ansible supports libvirt TLS [1] since the Train release, using client and server certificates for mutual authentication and encryption. However, this feature is not enabled by default, and requires certificates to be generated for each compute host. This change adds support for libvirt SASL authentication, and enables it by default. This provides base level of security. Deployments requiring further security should use libvirt TLS. [1] https://docs.openstack.org/kolla-ansible/latest/reference/compute/libvirt-guide.html#libvirt-tls Depends-On: https://review.opendev.org/c/openstack/kolla/+/833021 Closes-Bug: #1964013 Change-Id: Ia91ceeb609e4cdb144433122b443028c0278b71e
passwords.yml 4.88 KiB
---
###################
# External Ceph options
####################
# These options must be UUID4 values in string format
# XXXXXXXX-XXXX-4XXX-XXXX-XXXXXXXXXXXX
# for backward compatible consideration, rbd_secret_uuid is only used for nova,
# cinder_rbd_secret_uuid is used for cinder
rbd_secret_uuid:
cinder_rbd_secret_uuid:
###################
# Database options
####################
database_password:
# Password for the dedicated backup user account
mariadb_backup_database_password:
####################
# Docker options
####################
# This should only be set if you require a password for your Docker registry
docker_registry_password:
####################
# VMware support
####################
vmware_dvs_host_password:
vmware_nsxv_password:
vmware_vcenter_host_password:
nsxv3_api_password:
vmware_nsxp_api_password:
vmware_nsxp_metadata_proxy_shared_secret:
#####################
# Hitachi NAS support
#####################
hnas_nfs_password:
#######################
# Infoblox IPAM support
#######################
infoblox_admin_password:
####################
# OpenStack options
####################
aodh_database_password:
aodh_keystone_password:
barbican_database_password:
barbican_keystone_password:
barbican_p11_password:
barbican_crypto_key:
blazar_database_password:
blazar_keystone_password:
keystone_admin_password:
keystone_database_password:
grafana_database_password:
grafana_admin_password:
glance_database_password:
glance_keystone_password:
gnocchi_database_password:
gnocchi_keystone_password: