Using HTTP/HTTPS Proxies

PubSub+ Cloud supports deployments where you require or want to use an http or https proxies. You can use proxies to regulate your event broker service's access to the internet, or exclude them from public availability. You may need to use proxies to meet security requirements. Solace supports proxies in most situations and works with you to ensure that your security requirements are met with the proxy.

Solace supports using proxies for any of your connectivity requirements, however, when using proxies for Operational Connectivity between Home Cloud and the Mission Control Agent, there are some limitations you must consider. For more information, see Considerations When Using a Proxy for Operational Connectivity between Mission Control Agent and Home Cloud.

See Use Cases for some examples of why you may want to use a proxy.

In environments where access to the Internet needs to be restricted, you can configure a proxy with the http_proxy or https_proxy properties of your Kubernetes cluster deployment.

In simple terms, using HTTP/HTTPS proxies maintains security while providing convenience. Using an HTTP/HTTPS proxy you can:

Control your event broker service's traffic.
Hide the IP addresses of your event broker service and achieve online anonymity.
Work with the network restrictions of your environment.

If you choose to use a proxy, you must let Solace know at the time of deployment. This ensures that we generate a values.yaml file with the appropriate parameters for the Helm Chart. The customer must also provide details (URL, username, and password) of the HTTP/HTTPS proxy server to the Mission Control Agent when deploying it. The example below shows components that may be required for a proxy:

For any of you connectivity requirements,

proxy:
    https_proxy: "http://<USERNAME>:<PASSWORD>@<PROXY_SERVER_FOR_HTTPS>:<PORT>"
    http_proxy: "http://<USERNAME>:<PASSWORD>@<PROXY_SERVER_FOR_HTTP>:<PORT>"

As an example, a customer whose proxy is at proxyserver.customer.com:3341 with a username user1234 and password 3444password3232 would have the following entry in the values.yaml file.

datacenter:
  id: Solace-abc-test
  region: us-east-1
  httpsProxy: 'http://user1234:3444password3232@proxyserver.customer.com:3341'

Considerations When Using a Proxy for Operational Connectivity between Mission Control Agent and Home Cloud

If your security requires, Solace can configure the Operational Connectivity between the Mission Control Agent and Home Cloud to run through a proxy. Operational Connectivity carries the communications required to install the Mission Control Agent and to install, operate, and monitor event broker services. For more information, see Connectivity Model for Kubernetes Deployments.

When using a proxy for Operational Connectivity, you must be aware of the following considerations:

Solace supports only HTTP proxies. We tested support for HTTP proxies for Operational Connectivity using Squid and ZProxy.
Solace supports both authenticated and non-authenticated proxies
When using a proxy, it must support:
- HTTP CONNECT
- proxying to a non-443 port; in particular to port 55443
If your proxy supports SSL Inspection, you must disable the SSL Inspection for the regional hostname for the Mission Control Agent to PubSub+ Home Cloud (for example, production-ivmr.messaging.solace.cloud). For a list of host names by region, see Connection Requirements for PubSub+ Cloud Components .

Use Cases

There are numerous reasons you may decide to use a proxy. For deployments inside a private region, using a proxy is a simple method of controlling your services access to regions outside of your private region. The following use cases provide some examples where using a proxy can help manage event broker service access to the public Internet:

Secure Access to Public Internet

Perhaps you decide to permit access to the public Internet for the event broker services for outbound traffic. A proxy might be useful for outbound connections, such as RDPs (REST Destination Points). The event broker service can be configured to originate from a static IP address. The proxy makes it easier for applications outside of your deployment to whitelist. Proxies are useful in situations where you don't use a NAT or where you don't have a static IP address.

Managing Connections to Outside Services

For deployments inside a Customer-Controlled Regions, you can use a proxy as a method of controlling and managing access to services outside the Customer-Controlled Region with hostnames instead of IP addresses. For example, you may have a requirement for the Mission Control Agent to contact Datadog, which handles the monitoring data for event broker services. Because Datadog doesn't use static IP addresses, you can use a proxy to streamline the maintenance of connecting to Datadog and have the proxy determine whether a connection between the Mission Control Agent and Datadog is allowed using a hostname instead of IP addresses.

Provide feedback