Running a secure data node

Before reading this page, we recommend reading the validator node security page for useful security guidance. The following instructions describe how to set up a secure data node with exposed APIs.

As a node operator, you must provide TLS to the APIs exposed to the internet to provide secure communication between users and your server. GraphQL subscriptions won't work without TLS.

To setup a secure server, you have a few options:

• The data node has an internal mechanism to provide the TLS and auto-request for the certificate.
• A proxy service like nginx or caddy if you wish to pass requests with a DMZ.

The data node exposes 3 APIs with two separate ports:

• gRPC port: Default value is 3007 - used for gRPC API
• Gateway port: Default value is 3008 - used for the GraphQL and REST APIs.

You should expose both gRPC and Gateway with a TLS. However, the data node's internal mechanism allows you to expose only the Gateway port.

List of secure data nodes

The Vega consensus validators run publicly available data nodes. See a list of publicly available data nodes in the networks GitHub repository ↗. All of the listed (not commented) data nodes have TLS support.

Run a secure data node

A bit about TLS

The below examples show the autogenerated certificate from "Lets Encrypt", but you can also buy a different certificate or use the certificate you already own. Just be sure to provide paths to the certificate and key in your configuration.

If you decide to use the certbot to obtain the certficate please read the below documentation:

• Install certbot ↗
• Best practices for setting a cron job for Let's Encrypt (Certbot) renewal ↗

Use internal mechanism to expose Gateway

Follow on to use the internal data node mechanism to expose Gateway (GraphQL and REST APIs) with TLS.

Assumptions:

• Data node service is configured and running, or ready to start.
• You have the spare domain pointing to your server.
• You have free 443 port on your server where the data node is running.
• Your server is publicly available on the internet

Limitations:

Unfortunately, the data node cannot set up TLS for the gRPC port. It can be done only for the Gateway port (GraphQL and the REST APIs).

Automatic TLS

To configure the automatic TLS open the data node configuration file (<vega_home>/config/data-node/config.toml), and set the following settings in the data node config file:

YOUR_VEGA_HOME/config/data-node/config.toml

[Gateway]
  Port = 443
  IP = "0.0.0.0"
  HTTPSEnabled = true
  AutoCertDomain = "<gateway-domain>"

Then restart your node.

Ports for LetsEncrypt

It is a hard requirement of the LetsEncrypt validation process that the tool answering its challenge is running on the standard HTTP/HTTPS ports (80, 443).

If you are running behind a firewall, you need to port forward 80+443 to the machine generating the certificate for the duration of the creation process.

Use pre-generated certificates

Many administrators prefer to use a tool called certbot for generating and signing free certificates via LetsEncrypt. To obtain a signed certificate with this method:

• Install certbot
• Run certbot certonly --standalone to generate certificate
• Place the generated fullchain.pem into the Gateway.CertificateFile location and corresponding privkey.pem to Gateway.KeyFile.

YOUR_VEGA_HOME/config/data-node/config.toml

  [Gateway]
    HTTPSEnabled = true
    CertificateFile = "/path/to/certificate/file"
    KeyFile = "/path/to/key/file"

Use Nginx as proxy service

Assumptions:

• You have nginx >= 1.13 for the grpc_proxy feature.
• You have a certbot with the Nginx extension
• Your data node is running and exposing the gRPC API on port 3007 and Gateway on port 3008
• You have spare domains pointing to your server. Separated domains for the gRPC and the Gateway ports.

References:

• Nginx documentation

Example config

If you are going to use the certbot, prepare the following configuration for Nginx:

The Nginx configuration

server {
    server_name <grpc-domain>; # e.g server_name gprc.vega.mainnet.community;

    location / {
        grpc_pass grpc://127.0.0.1:3007; # it must point to your gRPC port on the data node

    }
    
    listen 80 http2;
}

server {
    server_name <gateway-domain>; # e.g server_name vega.mainnet.community;

    location / {
        proxy_pass http://127.0.0.1:3008; # This must point to your Gateway port on the data node

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
    }

    listen 80;
}

Next, generate certificates for your domains by executing the certbot command. Once certificates have been generated, you have to update the listen 443 ... line on your gRPC server to the following line listen 442 http2;.

The final config will look something like this:

The Nginx configuration

server {
    server_name grpc.vega.mainnet.community;

    location / {
        grpc_pass grpc://127.0.0.1:3007;

    }

    listen 443 http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/grpc.vega.mainnet.community/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/grpc.vega.mainnet.community/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    server_name vega.mainnet.community;

    location / {
        proxy_pass http://127.0.0.1:3008;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/grpc.vega.mainnet.community/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/grpc.vega.mainnet.community/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = vega.mainnet.community) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name vega.mainnet.community;

    listen 80;
    return 404; # managed by Certbot
}

server {
    if ($host = grpc.vega.mainnet.community) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name grpc.vega.mainnet.community;

    listen 80;
    return 404; # managed by Certbot
}

Use Caddy as a proxy service

Assumptions:

• Caddy 1.17+ is installed
• Your data node is running and exposing gRPC API on port 3007 and Gateway on port 3008
• You have spare domains pointing to your server. Separated domain for the gRPC and the Gateway ports.

References:

• Caddy documentation

Example config

The Caddy configuration

{
        email <admin-email-for-tls-purposes>
}


<gateway-domain>:443 {
        # REST & GraphQL
        route / {
                reverse_proxy http://127.0.0.1:3008
        }
        route /* {
                reverse_proxy http://127.0.0.1:3008
        }
}

<grpc-domain>:443 {
        reverse_proxy {
                to h2c://127.0.0.1:3007
                transport http {
                        versions h2c 2
                }
        }
}

The final config will look something like this:

{
        email admin@vega.mainnet.community
}


vega.mainnet.community:443 {
        # REST & GraphQL
        route / {
                reverse_proxy http://127.0.0.1:3008
        }
        route /* {
                reverse_proxy http://127.0.0.1:3008
        }
}

grpc.vega.mainnet.community:443 {
        reverse_proxy {
                to h2c://127.0.0.1:3007
                transport http {
                        versions h2c 2
                }
        }

}