No. The Ray security documentation says the Dashboard, Jobs and Client services give full access to the cluster, and anyone who can reach their ports can execute arbitrary code on it. Keep Ray inside a controlled network, and treat token authentication as an extra layer rather than a replacement.
What Ray assumes
Ray's documentation states that security and isolation must be enforced outside of the Ray cluster. It expects to run in a safe network environment and to act upon trusted code. Ray does not tell benign code from malicious code, so the people who deploy it decide who can reach it.
That design is reasonable for a distributed compute tool, but it surprises teams who open a port to look at a dashboard from home. A dashboard that feels like a read only status page is, per the docs, a way in. The REST APIs behind it can submit work.
The three doors
| Service | What it allows |
|---|---|
| Dashboard | REST APIs that can lead to code running on the cluster |
| Jobs | Submitting a Ray Job, which runs code |
| Client | Connecting and running tasks directly |
The docs call these developer tools that should only be used with access controls limiting them to trusted parties. They add that restricting network access to the dashboard port also protects job submission, since jobs run alongside it.
Token authentication
Ray 2.52.0 introduced built in token authentication as an additional layer against unauthorized access, including untrusted code execution. The page is firm that token authentication is not an alternative to a controlled network. A rollout note says Ray 2.59 enables token authentication by default for local clusters, and Ray 2.61 extends it to all clusters. Check your version before relying on either, because your cluster may be older.
TLS has a similar caveat. The docs say TLS for gRPC is not a replacement for network isolation.
A hardening checklist
- Put the cluster in a private subnet with no public address on the head node.
- Allow dashboard and job ports only from a small set of admin hosts or a VPN.
- Reach the dashboard through an SSH tunnel or an authenticating proxy you control, not a public listener.
- Turn on token authentication where your Ray version supports it.
- Give the cluster the smallest cloud role that works, since code that runs there inherits it.
- Keep other secrets off worker disks and out of environment variables where you can.
- Review who can submit jobs the way you review who can deploy to production.
How to find out if you are exposed
Ask your cloud provider for security group rules that allow broad access to the dashboard port, and list any load balancer in front of a head node. If you cannot say who can reach the port, treat it as exposed until proven otherwise.
Related reading: Jupyter server exposed to the network checklist, which covers a similar mistake in another ML tool.
Safeguard's asset discovery helps you find services you did not know were running, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Does TLS make the dashboard safe to publish?
No. The docs say TLS for gRPC does not replace network isolation.
Is the dashboard read only?
Per the Ray docs, its REST APIs can lead to code execution, so do not treat it as read only.
Sources
Last reviewed: 19 October 2026.
