No. According to the Dask distributed documentation, the default tcp address sends data unauthenticated and unencrypted, so TLS has to be switched on explicitly. A scheduler that anyone on the network can reach is also a place where code can be submitted, so treat network access to it as code execution access.
What the Dask TLS page states
The distributed documentation on TLS says the default tcp address sends data unauthenticated and unencrypted. With TLS enabled, the endpoints present certificates signed by a trusted certificate authority, which lets clients, schedulers and workers authenticate each other. The page says it is not possible to disable certificate verification, because that would expose connections to man in the middle attacks.
It also notes that the hostname or IP address a certificate was issued for is not checked, and says a custom internal certificate authority should make that acceptable. A require_encryption setting exists to stop anyone from using plain TCP by accident.
Why this matters more than a typical service
A Dask scheduler distributes Python work to workers. The docs for one scheduler method carry a caution that it runs arbitrary Python code on the scheduler. That is a documented feature for diagnostics, not a bug, but it shows the shape of the system: reaching the cluster is closer to having a shell than to calling a read-only API.
The pages reviewed for this post do not set out a formal threat model, so none is claimed here. The conservative reading is the useful one. Anyone who can talk to the scheduler should be someone you would trust to run code on your workers.
A hardening checklist for shared clusters
- Keep the scheduler and workers on a private network segment, not on a public address.
- Allow inbound connections only from the machines and users that need them, using network policy or security groups.
- Turn on TLS for scheduler, worker and client connections, using a certificate authority you control.
- Set
require_encryptionso an unencrypted connection fails loudly. - Give workers the minimum cloud credentials, because anything that runs on a worker can use them.
- Log who connects, and review that list.
- Do not run clusters on a laptop with a port forwarded to the internet.
Common mistakes
| Mistake | Better practice |
|---|---|
| Testing with a public IP and leaving it | Use a private network or a tunnel from the start |
| One broad role on every worker | Scope credentials per job type |
| Assuming a dashboard login protects the scheduler port | Protect the network path and enable TLS |
| Treating TLS as optional because the network is "internal" | Internal networks include compromised hosts |
Where Safeguard fits
Safeguard's asset discovery and dependency scanning can help you find where Dask and its related packages are in use across repositories, so you know which clusters to review. A free scan is a quick start.
Quick check
Can I turn off certificate checking for a test cluster?
The Dask TLS page says it is not possible to disable certificate verification. Use a throwaway internal certificate authority for tests.
Does enabling TLS replace network controls?
No. TLS authenticates and encrypts connections, but you should still restrict who can reach the cluster.
Sources
Last reviewed: 19 October 2026.
