Using HTTP/HTTPS Proxies

PubSub+ Cloud support s deployments that require or want to use http or https proxies. Whether you want to regulate access to the internet for your event broker services, or simply don't want your event broker services to be publicly accessible, Solace works with you to ensure your proxy related security requirements are met. 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 may want to use proxies. Proxy usage can be configured 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.
  • Work with the network restrictions of your environment.
  • Hide the IP addresses of your event broker service and achieve online anonymity.

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:

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'

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.