🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

@zmoog The only remark I have here is that 5672 is unencrypted AMQP traffic and should not be opened. I can confirm it is not needed, it works when only 5671 is allowed. I'd really advice to check

*.servicebus.windows.net:5671
*.blob.core.windows.net:443

Also when you nslookup the servicebus URL, you get 3 *.cloudapp.net Url's which Also need to be allowed.

When the *.cloudapp.net url's are not allowed, it does not work

The only remark I have here is that 5672 is unencrypted AMQP traffic and should not be opened. I can confirm it is not needed, it works when only 5671 is allowed. I'd really advice to check

When the *.cloudapp.net url's are not allowed, it does not work

Thank you @willemdh, I'll double check both the ports and the URLs.

According to the AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide, is seems the service on port 5672 performs a mandatory upgrade of connection to TLS:

Azure Service Bus or Azure Event Hubs requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model.

In the same document, in the AMQP outbound port requirements section, it lists both ports:

Clients that use AMQP connections over TCP require ports 5671 and 5672 to be opened in the local firewall.

So my current understanding is that using both 5671 and 5672 ports is not insecure because the service requires a mandatory upgrade to TLS.

I also noticed the document mentions the need for additional ports the EnableLinkRedirect is enabled:

Along with these ports, it might be necessary to open additional ports if the EnableLinkRedirect feature is enabled. EnableLinkRedirect is a new messaging feature that helps skip one-hop while receiving messages, thus helping to boost throughput. The client would start communicating directly with the back-end service over port range 104XX [...]

Personally, I never enable this option, but I want to learn more.

@alaudazzi, I made a few minor additions. Would you mind taking a final look? 🙇

💚 Build Succeeded

• Buildkite Build
• Commit: 9188dc2

History

• 💚 Build #9217 succeeded fb1b99d
• 💚 Build #9213 succeeded da0f072
• 💔 Build #9212 failed b4f3816d0227cb55b13870abc3befa61d9ec111e
• 💔 Build #9209 failed 98a1fe451dfef68962070e509b62eb01bdd88001
• 💚 Build #9021 succeeded bb32baa497697c9401a7c0dd1099602f37907ad5
• 💚 Build #8967 succeeded 9b3914a3c7f30a841ee94c963fd3be8f996cc22c

cc @zmoog

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

Package azure - 1.9.2 containing this change is available at https://epr.elastic.co/search?package=azure