proxy.hpc.ut.ee¶

HAProxy is an open-source load balancer and reverse proxy for TCP and HTTP traffic. UTHPC uses it to serve both its own services and user applications. To ensure high availability, the proxy service operates on two physical servers that make up the proxy.hpc.ut.ee cluster.

The purpose of this service is to provide:

• Managed and automated TLS
• Security best practices
• Good default user-facing HTTP security
• Dynamic discovery capability
• High availability and load-balancing capability

Overview of the proxy design¶

Basics¶

HAProxy is a reverse proxy between client devices and web/backend servers. The proxy forwards client requests to backend servers and returns the server's responses to the clients. This means that clients are not in direct communication with the backend applications. The HAProxy service acts as a traffic controller and can filter out malicious requests, distribute requests between identical backends, and handle SSL/TLS encryption and decryption.

Keep in mind that UTHPC system administrators maintain all the proxy configurations and certificates to enforce security, monitoring and best practices.

SSL termination¶

UTHPC HAProxy cluster is capable of doing SSL termination. This means that web servers can offload SSL encryption and decryption to the HAProxy machines, reducing the complexity of the applications and saving some CPU usage. SSL termination also simplifies the administration of certificates, as they are all kept securely in the UTHPC Vault instance and are managed only by the UTHPC infrastructure team.

Miscellaneous information¶

• The rate limit is set to 500 requests per 10 minutes for each client.

Best practices and other information for development¶

Content Security Policy (CSP)¶

Content Security Policy (CSP) is a feature that adds additional security to the clients accessing your applications by controlling which resources the client's browser can load and execute. We enforce some basic CSP rules at the proxy level to provide centralized security and to prevent simple cross-site scripting (XSS) and clickjacking attacks. These rules get applied only for sites that don't define their own CSP rules.

The CSP rules are delivered to the client's browser using a Content-Security-Policy response header. This header contains a series of directives that are separated by semicolons. The default header we enforce looks like this:

Content-Security-Policy: report-uri https://csp.hpc.ut.ee/log; form-action 'self'; frame-ancestors 'self'

You can see that the header contains three different directives:

As previously mentioned, these rules are applied only to backends that do not already populate the Content-Security-Policy response header. If an application sets this header, the proxy will not modify it, ensuring that the application retains full control over its CSP rules. This approach grants developers greater flexibility in defining security policies. However, exercise caution when making your own CSP rules—overly permissive configurations can leave your application vulnerable to malicious activity.

Other security headers¶

Keep in mind the paths your application serves¶

Sometimes, it is more advantageous to use a single domain and forward the traffic to different backend servers based on the path in the client's request. This is referred to as path-based routing.

Routing traffic to a specific backend based on the path's prefix is simple and does not require a lot of configuration. The same does not apply to rewriting the request. While possible, experience shows that changing the request URLs on the proxy level requires complex and sometimes error-prone configurations in the proxy. These configuration lines can't be easily populated using a template and must be handled case-per-case by the UTHPC infrastructure team.

By designing applications to serve the same paths that the client device tries to request, the proxy configuration can be kept as simple as possible. This also means that making changes in the path-based routing structure will be simpler because the magnitude of changes that the proxy configuration needs will be smaller. Overall, you will have more control over how your application behaves while maintaining the capability to use a single domain for different backend servers.

Using the UTHPC HAProxy service¶

UTHPC team provides the HAProxy service through our proxy cluster called proxy.hpc.ut.ee. Setting up the application behind the proxy requires some specific activities:

1. Pointing the domain name to proxy.hpc.ut.ee.
2. Configuring the routes inside UTHPC proxy servers to direct the domain's traffic to the specified backend.
3. Requesting a TLS certificate from a public certificate authority.
4. Installing TLS certificates for the domain name.

If the domain name used is managed by UTHPC (for example *.hpc.ut.ee), UTHPC infrastructure team directs the domain to HTTP Proxy cluster proxy.hpc.ut.ee, installs HTTPS certificates on the proxy, and routes the traffic through the proxies to the backend servers.

Other domains need to be pointed at the proxy.hpc.ut.ee proxy servers by domain owners, with either A or CNAME DNS records. In this case, the last three steps are done by UTHPC system administrators.

web-app.example.ee. IN CNAME proxy.hpc.ut.ee.

example.ee. IN A 193.40.46.68
example.ee. IN A 193.40.46.69

If you need to publish an app or web page, don't hesitate to contact UTHPC support with the name/port of your service and the domain you would like to use.