Protecting the Firedancer UI in an Enterprise Environment

With all the buzz around firedancer lately, we at Sol Strategies wanted to give the public some insight into the performance of our validators running Firedancer! Firedancer ships with a really cool UI, however exposing such a UI to the internet can introduce performance and security risks that come with things such as DDoS attacks. We didn’t want that to stop us and don’t want it to stop other operators as well, so we wanted to share a guide on how we are securing our ingress to give other operators some inspiration on how best to secure their Firedancer UI should they decide to make it public as well!

Our environment and ingress consists of:

• Cloudflare
• EKS (kubernetes). All nodes running on private subnets.
• Traefik ingress controller
• Firedancer node running outside of AWS
• VPN connecting AWS and all DC’s together secured by ACLs and firewall rules

The path for our Firedancer UI ingress is:

Cloudflare -> AWS NLB -> Traefik (EKS) -> K8s Service -> K8s Endpoint -> VPN -> Firedancer

The main motivations for this are:

• Block malicious traffic at the edge (Cloudflare) to not overload the validator
• Forward all ingress logs to our log aggregation system to meet our standards for ISO 27001 / SOC 2 compliance.
• Have all parts of the ingress in IaaC (infrastructure as code)

Firedancer Configuration

All of our nodes have an interface on them with a private IP on them so traffic can be routed between environments, depending on network ACLs and firewalls. This gives us the benefit of being able to bind the firedancer GUI on a private IP. To set up the Firedancer to bind on a private interface, update your config.toml with the following configuration.

Cloudflare configuration

Deploy a DNS record pointing to your load balancer. Make sure to proxy the record. A terraform locals snippet:

If you want to do TLS termination at:

• Cloudflare: Set your SSL mode to flexible.
• Ingress: Set your SSL mode to full or full (strict).

Traefik Configuration

Next, we create an IngressRoute as well as a Middlewareto listen for traffic on a specific hostname as well as adding and removing some specific headers.

IngressRoute CRD

Middleware CRD

Kubernetes Configuration

Next we create a serviceandendpoint in Kubernetes. Optionally, you can set up something like nginx, however the below set up we viewed as simpler with less maintenance.

Service

Endpoint

Check it out for yourself at https://fd.solstrategies.io/!