Cannot use operator with tls enabled rabbitmq cluster

[olfway]

Describe the bug

My rabbitmq cluster has tls certificate for *.some.domain.com,
but topology operator tries to connect to https://operator.test-2.svc:15671 and fail with an error:
x509: certificate is valid for *.test-2.some.domain.com, test-2.some.domain.com, not operator.test-2.svc

But for my applications I have to have a valid *.some.domain.com cert and cannot use self-signed one for operator.test-2.svc

There probably should be a way to provide a hostname for topology operator to connect to

Version and environment information

• Messaging Topology Operator: 1.1.0
• RabbitMQ Cluster Operator: 1.8.3

[starkers]

👍🏼 we're experiencing similar frustrations ourselves

Edit: It seems that the operator infers the hostname by tracing the Service of the RabbitmqCluster.. maybe we can extend the operator to look for some kind of custom Configmap object or annotation instead? Allowing users to tell the operator exactly which url to connect to.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

[Zerpet]

Hey folks, we discussed this issue in our internal sync up and we are going to prioritise it. We think the Operator should work in any TLS setup and this can be considered a bug. Thank you for reporting this!

[coro]

This can be an extension of the RabbitmqClusterReference object, removing the implicit assumption that the cluster-local address is fine:

type RabbitmqClusterReference struct {
	// The name of the RabbitMQ cluster to reference.
	// +kubebuilder:validation:Required
	Name string `json:"name"`
	// The namespace of the RabbitMQ cluster to reference.
	// Defaults to the namespace of the requested resource if omitted.
	// +kubebuilder:validation:Optional
	Namespace string `json:"namespace"`
	// The hostname used to connect to the RabbitMQ Cluster on which this topology object will be created.
        // If unset, defaults to the cluster-local DNS address `name.namespace.svc`
	// +kubebuilder:validation:Optional
	Hostname string `json:"hostname"`
}

[masterphenix]

Hello, we are currently blocked with this issue also.
We have production rabbitmq clusters on VMs, and are considering migrating them to Kubernetes by using the cluster and messaging topology operators, which are really promising, easy to use, maintain and monitor.
However, not being able to use a trusted certificate alongside with the Messaging Topology Operator is blocking us, and prevents us from going further at this point.
Any estimate on when a fix could be released ? Or maybe a workaround in the mean time ?

[davemaul]

Same here. It'd be great if there was a fix soon.

[Zerpet]

This can be an extension of the RabbitmqClusterReference object, removing the implicit assumption that the cluster-local address is fine:

type RabbitmqClusterReference struct {
	// The name of the RabbitMQ cluster to reference.
	// +kubebuilder:validation:Required
	Name string `json:"name"`
	// The namespace of the RabbitMQ cluster to reference.
	// Defaults to the namespace of the requested resource if omitted.
	// +kubebuilder:validation:Optional
	Namespace string `json:"namespace"`
	// The hostname used to connect to the RabbitMQ Cluster on which this topology object will be created.
        // If unset, defaults to the cluster-local DNS address `name.namespace.svc`
	// +kubebuilder:validation:Optional
	Hostname string `json:"hostname"`
}

I've started working towards this solution, but I'm unsure about the user experience with this approach. Essentially, down this road, a user would have to update all existing topology objects and update the rabbitmqClusterReference, which is prohibited by our webhooks, leading us to also change the webhooks for all our types; what an insane amount of work for us and for the users, just to pass a domain suffix!

More over, the cluster domain is never unlikely to change and it's very likely always the same, therefore I don't see much reason to make the domain suffix configurable per topology object. It seems more sensible to configure this property once, and apply it to all topology objects.

Given the above, I'm considering two options:

1. Provide an command-line option and env var to configure the cluster domain suffix
2. Do a CNAME DNS query in the main function, on startup, and figure the domain suffix

Option 1 has the downside that users won't be able to just kubectl apply -f <link to manifest>, as they will have to add this environment variable or CLI option in the args.

Option 2 has the downside that we have to assume that some service exists, probably the kubernetes.default.svc. We can always fallback to no-domain name if this service does not exist, or the query is not successful. This also assumes that the DNS service allows for CNAME queries.

Does anybody have a preference?