You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In some cases e.g, when using cert-managers CSI driver TLS keys+CA cert can be directly mounted to the pods. Also the now possibly outdated mtls inter node example mounts secrets manually. Right now such cases are not really supported since many feature rely on tls.secretName being set for tls to be considered enabled and tls.caSecretName for mtls e.g.,
Meaning that while it is possible to configure the rabbitmq nodes themselves to run with TLS/mtls using such directly mounted secrets, by also configuring the TLS config directly as is done in the MTLS example, it is not possible to utilise the operators other features related to TLS.
Describe the solution you'd like
This could be solved with backwards compatibility by adding an extra configuration option to force TLS to be enabled even in the absence of tls.secretName e.g., tls.enabled, if necessary a second option could also be added as switch for the MTLS features handled by the operator.
Describe alternatives you've considered
Another option could be instead of having just a simple flag to also allow to pass file paths instead of just secret refs
e.g., tls.secretPath and tls.caSecretPath and then treat them essentially the same as their secret ref equivalents.
Additional context
Also note that using e.g., the cert-manager CSI driver allows you to easily create TLS secrets specific to the pod running. So each cluster node gets their own cert automatically making it a bit easier to scale. So supporting this use case would be beneficial overall.
Example config with cert-manager CSI driver
apiVersion: cert-manager.io/v1kind: Issuermetadata:
name: rabbitmq-ca-issuernamespace: testspec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1kind: Certificatemetadata:
name: rabbitmq-canamespace: testspec:
isCA: truesecretName: rabbitmq-cacommonName: rabbitmq-caissuerRef:
name: rabbitmq-ca-issuerkind: Issuergroup: cert-manager.io
---
apiVersion: cert-manager.io/v1kind: Issuermetadata:
name: rabbitmq-canamespace: testspec:
ca:
secretName: rabbitmq-ca
---
apiVersion: v1kind: ConfigMapmetadata:
name: mtls-inter-node-tls-confignamespace: testdata:
inter_node_tls.config: | [ {server, [ {cacertfile, "/etc/rabbitmq/certs/ca.crt"}, {certfile, "/etc/rabbitmq/certs/tls.crt"}, {keyfile, "/etc/rabbitmq/certs/tls.key"}, {secure_renegotiate, true}, {fail_if_no_peer_cert, true}, {verify, verify_peer}, {customize_hostname_check, [ {match_fun, public_key:pkix_verify_hostname_match_fun(https)} ]} ]}, {client, [ {cacertfile, "/etc/rabbitmq/certs/ca.crt"}, {certfile, "/etc/rabbitmq/certs/tls.crt"}, {keyfile, "/etc/rabbitmq/certs/tls.key"}, {secure_renegotiate, true}, {fail_if_no_peer_cert, false}, {verify, verify_none}, {customize_hostname_check, [ {match_fun, public_key:pkix_verify_hostname_match_fun(https)} ]} ]} ].
---
apiVersion: rabbitmq.com/v1beta1kind: RabbitmqClustermetadata:
name: rabbitmqcluster-samplenamespace: testannotations:
rabbitmq.com/topology-allowed-namespaces: "test2"spec:
rabbitmq:
envConfig: | SERVER_ADDITIONAL_ERL_ARGS="-proto_dist inet_tls -ssl_dist_optfile /etc/rabbitmq/inter-node-tls.config" RABBITMQ_CTL_ERL_ARGS="-proto_dist inet_tls -ssl_dist_optfile /etc/rabbitmq/inter-node-tls.config"terminationGracePeriodSeconds: 60replicas: 3# if you remove this tls block this will actually deploy fine with the current version# of the operator but will not set any TLS ports in the services etc.tls:
enabled: true# can't be set because the operator considers TLS to not be activedisableNonTLSListeners: trueoverride:
statefulSet:
spec:
template:
spec:
containers:
- name: rabbitmqvolumeMounts:
- mountPath: /etc/rabbitmq/certsname: mtls-inter-node-nodes-tls
- mountPath: /etc/rabbitmq/inter-node-tls.configname: inter-node-configsubPath: inter_node_tls.configvolumes:
- configMap:
defaultMode: 420name: mtls-inter-node-tls-configname: inter-node-config
- name: mtls-inter-node-nodes-tlscsi:
driver: csi.cert-manager.ioreadOnly: truevolumeAttributes:
csi.cert-manager.io/issuer-name: rabbitmq-cacsi.cert-manager.io/common-name: "${POD_NAME}.${POD_NAMESPACE}.svc.cluster.local"csi.cert-manager.io/dns-names: "${POD_NAME}.${POD_NAMESPACE}.svc.cluster.local"
The text was updated successfully, but these errors were encountered:
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.
This is valueable and an interesting feature. Unfortunately, it's seems a considerable undertaking and we don't have the bandwidth to do this right now. A PR would be very welcome.
Is your feature request related to a problem? Please describe.
In some cases e.g, when using cert-managers CSI driver TLS keys+CA cert can be directly mounted to the pods. Also the now possibly outdated mtls inter node example mounts secrets manually. Right now such cases are not really supported since many feature rely on
tls.secretName
being set for tls to be considered enabled andtls.caSecretName
for mtls e.g.,Meaning that while it is possible to configure the rabbitmq nodes themselves to run with TLS/mtls using such directly mounted secrets, by also configuring the TLS config directly as is done in the MTLS example, it is not possible to utilise the operators other features related to TLS.
Describe the solution you'd like
This could be solved with backwards compatibility by adding an extra configuration option to force TLS to be enabled even in the absence of
tls.secretName
e.g.,tls.enabled
, if necessary a second option could also be added as switch for the MTLS features handled by the operator.Describe alternatives you've considered
Another option could be instead of having just a simple flag to also allow to pass file paths instead of just secret refs
e.g.,
tls.secretPath
andtls.caSecretPath
and then treat them essentially the same as their secret ref equivalents.Additional context
Also note that using e.g., the cert-manager CSI driver allows you to easily create TLS secrets specific to the pod running. So each cluster node gets their own cert automatically making it a bit easier to scale. So supporting this use case would be beneficial overall.
Example config with cert-manager CSI driver
The text was updated successfully, but these errors were encountered: