Shared Load Balancer

The platform relies on various Shared Load Balancer (SLB) infrastructure components to manage all incoming requests (excluding direct connections via public IP) directed towards the hosted environments. SLB acts as an NGINX proxy server, bridging the connection between the client side (e.g., a web browser) and the applications deployed on the platform.

Shared Load Balancers (SLBs) serve as intermediaries between external requests and the platform’s internal network, directing traffic to the necessary applications. To safeguard against Distributed Denial of Service (DDoS) attacks, SLBs limit connections from a single source address to 50 simultaneous connections.

The platform employs multiple synchronized SLBs distributed across different hosts to maintain high availability. These SLBs share the same data storage, enabling seamless interchangeability. If one SLB instance fails, others are ready to assume its responsibilities without interruption.

Deny Access Via SLB

Within the platform, there’s a convenient predefined option to prevent external access to environment nodes via the Shared Load Balancer (SLB). By toggling the “Access via SLB” option in the topology wizard, you can swiftly disable access to containers using their default domain names. This feature eliminates the need for additional steps like adding public IP addresses or adjusting firewall settings, simplifying the process to just a single click.

The platform’s default setting enables the “Access via SLB” feature for each layer, providing the following functionalities:

• The “Open in Browser” button within the dashboard conveniently opens the relevant service (e.g., a database admin panel).
• Nodes are reachable from the Shared Load Balancer (SLB) using environment domain names and default ports (80, 8080, 8686, 8443, 4848, 4949, 7979).
• Links to nodes are included in emails if necessary.

However, you have the option to manually disable the “Access via SLB” feature, resulting in the following changes:

• Attempting to access pages via the “Open in Browser” button results in a 403 Forbidden error instead of accessing the intended service.
• Nodes become inaccessible from the Shared Load Balancer, effectively isolating the layer from SLB.
• Access via SSH and through endpoints remains unaffected.
• Links to nodes are omitted from emails.
• For enhanced visibility, layers with disabled SLB access are clearly labeled in the dashboard.

After disabling SLB access, attempting to connect to nodes via the default URL will result in displaying an error page instead of accessing the default service.

Here are some common scenarios where you might use the Access via SLB feature:

• Set up a topology that allows connections via the environment load balancer but blocks direct access to containers via URLs.
• Prevent SLB access to nodes with public IP addresses and custom domains configured, enhancing security.
• Restrict public access via SLB to nodes that should only be accessed internally, such as databases.

While it’s suitable to use the Access via SLB option for development and testing environments, it’s recommended to disable this feature for production applications. Instead, opt for using a public IP address with a custom domain for improved security and control.