private-address is set as a hostname for amqp relation instead of a local hostname
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack RabbitMQ Server Charm |
Triaged
|
Medium
|
Unassigned |
Bug Description
In order to implement inter-node TLS termination for secure cluster connectivity and also for clients to initiate and negotiate secure connections to rabbitmq servers (while still using password auth) X.509 TLS certificates need to contain Subject Alternative Name fields (https:/
https:/
TLS clients generally follow https:/
Those names are currently retrieved via gethostname(2) in the charm code from the current UTS namespace and are also exchanged between different rabbitmq-server units and added to /etc/hosts (presumably to avoid DNS resolution dependency). This is done only for "cluster" relation between rabbitmq peers.
For rabbitmq clients this is not the case and they use a list of "private-addresses" (rabbit uses get_unit_ip which relies on network spaces but a hostname is needed here). This is both because rabbitmq does not use a hostname and passes an IP address and also because charm-helpers explicitly use private-address (the same is valid for both classic and reactive charms).
https:/
rabbit_hosts = 10.232.
cluster relation handling
https:/
https:/
https:/
amqp relation handling
https:/
In this case clients will connect via IP addresses and, even if the SubjAltName field contains all rabbitmq hostnames, validation will fail due to a mismatch.
Changed in charm-rabbitmq-server: | |
status: | New → Triaged |
importance: | Undecided → Medium |