Using Proxies

Solace Cloud supports deployments using http, https, and SOCKS5 proxies. You can use proxies to regulate, or exclude your event broker service's access to the internet, or you may require 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 can configure your deployment to use proxies for all of your connectivity requirements; however, there are some limitations you must consider when using proxies for Operational Connectivity between the Home Cloud and Mission Control Agent, which can have up to five main connections as outlined in Connectivity Model for Kubernetes Deployments.

In environments where you want to restrict access to the internet, you can configure a proxy with the http_proxy, https_proxy, or all_proxy (for SOCKS5) properties of your Kubernetes cluster.

In simple terms, using proxies maintains security while providing convenience. Using a proxy allows you to:

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.

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

If you choose to use a proxy, you must let Solace know at the time of deployment. You must provide the host, port, protocol, username, and password information for your proxy server. We use this information to configure the <datacenter-name>-values.yaml file with the appropriate parameters for the Helm Chart to deploy the Mission Control Agent. If you intend to use distributed tracing, you can supply a list of proxy exclusions to selectively bypass proxy routing for specific destinations like a self-hosted observability platform.

The example below shows components that may be required for a proxy:

proxy:
  ivmr:
    enabled: false
  distributedTracing:
    noProxy:
      enabled: false
      hosts: []
  host: ""         # must be provided
  protocol: "http" # options are http, https, or socks5
  port: ""
  username: ""     # must be provided
  password: ""     # must be provided

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.

proxy:
  ivmr:
    enabled: false
  distributedTracing:
    noProxy:
      enabled: false
      hosts: []
  host: "proxyserver.customer.com:3341"
  protocol: "http" 
  port: ""
  username: "user1234"
  password: "3444password3232"

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 Solace 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. The proxy settings are also used for connections through Solace Cloud between event broker services and Event Portal. For more information, see Connecting Event Broker Services to Event Portal Through Solace Cloud.

We support authenticated and non-authenticated HTTP and SOCKS5 proxies. While we tested HTTP proxy support for Operational Connectivity using Squid and Zscaler, any proxy that meets the following requirements should work:

For HTTP/HTTPS proxies, your proxy must support:
- HTTP CONNECT
- proxying to a non-443 port; in particular to port 55443
For SOCKS5 proxies, your proxy must support the SOCKS5 protocol for TCP tunneling 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 Solace Home Cloud (for example, production-ivmr.messaging.solace.cloud). For a list of host names by region, see Connection Requirements for Solace Cloud Components .

Configuring Proxy Exclusions for Distributed Tracing

Distributed tracing supports only HTTP or HTTPS proxies.

If you are using distributed tracing, and an HTTP or HTTPS proxy, Solace can configure a NO_PROXY exclusion list to selectively bypass proxy routing for specific destinations while maintaining proxy routing for all other traffic. Proxy exclusions are useful when you need to send traces to internal or on-premises systems that should not route through your corporate proxy, while still routing external services through a proxy for security compliance.

For more information, see Using Distributed Tracing with a Proxy in a Customer-Controlled Cluster.

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 Customer-Controlled Clusters, you can use a proxy as a method of controlling and managing access to services outside the Customer-Controlled Cluster 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