Security settings

Here we present a few common security fields you’ll likely want to configure in a production deployment.

Enabling TLS

As a web application, any production deployment of Dask-Gateway should be run with TLS encryption (HTTPS) enabled. There are a few common options for enabling this.

Using your own TLS certificate

If you have your own TLS certificate/key pair, you can specify the file locations in your file. The relevant configuration fields are:

c.DaskGateway.tls_cert = "/path/to/my.cert"
c.DaskGateway.tls_key = "/path/to/my.key"

Note that the certificate and key must be stored in a secure location where they are readable only by admin users.

Using letsencrypt

It is also possible to use letsencrypt to automatically obtain TLS certificates. If you have letsencrypt running using the default options, you can configure this by adding the following to your file:

c.DaskGateway.tls_cert = "/etc/letsencrypt/live/{FQDN}/fullchain.pem"
c.DaskGateway.tls_key = "/etc/letsencrpyt/live/{FQDN}/privkey.pem"

where FQDN is the fully qualified domain name for your server.

Using external TLS termination

If dask-gateway-server is running behind a proxy that does TLS termination (e.g. NGINX), then no further configuration is needed.

Proxy authentication tokens

To secure communication between the proxies and the gateway server, a secret token is used for each proxy. By default these tokens are generated automatically. It’s necessary for an admin to configure these explicitly if the proxies are being externally managed (i.e. c.WebProxy.externally_managed/c.SchedulerProxy.externally_managed are set to true). To do this you have two options:

  • Configure c.WebProxy.auth_token and c.SchedulerProxy.auth_token in your file. Since these fields are secrets, the config file must be readable only by admin users.

  • Set the DASK_GATEWAY_PROXY_TOKEN environment variable. In this case both proxies will share the same token. For security reasons, this environment variable should only be visible by the gateway server and proxy processes.

In either case all options take 32 byte random strings, encoded as hex. One way to create these is through the openssl CLI:

$ openssl rand -hex 32