-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support amqps #1827
Comments
After significant time spent to get SSL configured on my local RabbitMQ instance, I have looked into this. The rabbit hole (pun intended) goes just a bit deeper than I originally expected. Status quoCurrent supportOur current support assumes (or has the constraint) that what is passed to Cloud providersDepending on how the connection properties are available from cloud providers, the viable solutions may change. It's a shame I didn't investigate this more before.
Or are the individual parts (username/password/host etc.) also provided as separate properties to some degree? I'll try to do my due diligence on this tomorrow so we can best support what most Zipkin users may end up using. I'm out of time to look this up today, though. Without a single property provided by the RabbitMQ Java client that can parse the RabbitMQ URI spec for multiple hosts, it's not easy to support both of these options. To be fair, the URI spec doesn't define multiple hosts as valid. Quickest solution?The flag for using TLS can be set separately,
With a flag exposed for that as say This solution feels like it avoids fixing the limitations with our current configuration options, which may be fine if it works for the vast majority of users, but I fear it may not. Parse all the URIsA more robust solution compared to above might be the following, which tries to define a version of the RabbitMQ URI spec that handles multiple hosts. I think ideally we would be able to take a string that optionally contains a scheme, username, password, virtual host, port, and requires at the least one host but has potentially multiple hosts. Then, being able to pass that to the RabbitMQ client and let it parse it would be a cherry on top. Until that happens, we'll have to parse it ourselves. There are subjective decisions that need to be made for what is allowed in the string, though. We could take inspiration from the MongoDB client's format.
Which would make ours something like:
We could also consider parsing query parameters at the end. This could provide a way for users to pass the necessary files for full TLS configuration with a trust manager. Reasonable (IMO) limitations the above implies are that all hosts would be connected to using the same scheme, authentication, and virtual host. Sorry for the length of the above. I'm glad to hear other solutions if anyone has them, or feedback on anything above. |
Hello, Please see the format of rabbitmq(amqps) provided in PCF. We tried to parse and hardcode the values such as addresses, vhost, user, password and it keeps saying "connection refused". "p-rabbitmq": [ |
@shakuzen I'd go for RABBIT_SSL_ENABLED if it works for PCF as it can defer the more difficult options to later. It is hard to foresee configuration all providers might need and in general we try to make sure we know concretely what we support. Do you have a PCF account? @reshmik do you have one that can be borrowed? |
Yes most definitely, I have created a new space and given you space manager, dev permissions. You can deploy code and add services from marketplace there. I can assist with additional testing time permitting this week(since we will be at Spring One).@shakuzen : please give me your best email so I can add you as well. |
@reshmik I'm at SpringOne this week also, so we could all gather for a quick hacking and testing session. I also have my local setup with amqps now for testing. I have another question now: are you making a custom Zipkin server so you can extract the properties from vcap services and set them for the corresponding Zipkin properties, or how are you getting them set? |
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See openzipkingh-1827
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See openzipkingh-1827
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See openzipkingh-1827
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See openzipkingh-1827
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See gh-1827
Allows users to set a flag to use SSL when connecting to the RabbitMQ server via AMQPS. See openzipkingh-1827
Hi I'm raising this question rather than create a new feature request since it looks like it is in the same area. Apologies if this is the wrong place. I am trying to integrate zipkin into a RabbitMQ configured with Mutual TLS. The above describes some updated support where zipkin uses the dummy 'trust everything' TrustManager, which is fine. My problem is that the current approach, I think, is hard coded to set up a dummy/empty KeyStore. This means that our RabbitMQ rejects the connection because it doesn't see an acceptable client certificate coming from Zipkin client. Is it possible to update the ZipkinRabbitMQCollectorProperties or equivalent to optionally create an SSLContext that uses the dummy trust manager, but allows a 'real' KeyStore to be configured? and then call connectionFactory.useSslProtocol, specifying the SSLContext just created? Or some other mechaism to allow a KeyStore to be injected? I tried setting JAVA_OPTS to default to a keystore file, but it is just ignored by the hard-coded logic If there is another approach or workaround already in use I'd be grateful to hear about it |
Currently, our RabbitMQ collector (and sender) doesn't configure or test for amqps. We should fix that as this impacts the ability to use in environments such as cloud foundry
Thx for figuring this out @reshmik
related: spring-projects/spring-boot#6401
cc @shakuzen @marcingrzejszczak
The text was updated successfully, but these errors were encountered: