Security

Ray’s security model, threat assumptions, and how to report vulnerabilities.

Threat model

Ray is designed for trusted environments. By default, Ray clusters assume:

• All processes in the cluster trust each other.
• Anyone with network access to the GCS port can submit work to the cluster.
• The dashboard exposes job submission and remote code execution.

For multi-tenant or untrusted-input deployments, place the cluster behind a network boundary (VPC, private subnet, Kubernetes namespace) and add an authenticated proxy in front of the dashboard.

Authentication

Ray itself does not enforce authentication on the GCS, dashboard, or worker ports. For authenticated access:

• Front the dashboard with an OAuth proxy (oauth2-proxy, Cloudflare Access, your platform’s ingress).
• Use Kubernetes RBAC and KubeRay’s auth integrations for cluster-level access control.

Network exposure

Restrict which networks can reach Ray ports:

• 6379: GCS — restrict to the cluster’s private network.
• 8265: Dashboard / Jobs API — restrict to your operations network.
• 10001: Ray Client — generally avoid; prefer the Jobs API.

Reporting vulnerabilities

Email [e-mail] with a description of the issue and reproduction steps. The Ray security team will acknowledge within five business days and coordinate a fix.

Do not file security issues as public GitHub issues.

Disclosure

The team coordinates with reporters on timing. Fixes typically ship in the next patch release; severe issues may trigger an out-of-band release.

Next steps

Cluster setup

Network and cluster configuration.

Configure dashboard

Restrict dashboard access.