Ray on Vertex AI
To run ray on vertex ai, teams build a managed cluster in Google Cloud. Then they submit distributed Python jobs from a notebook or a local script. Most teams start by assigning a shared service account to the cluster nodes. If that role is too broad, any user job can read private buckets. It can also query production databases without limits. How ray on vertex ai manages clusters and roles Ray is an open framework for scaling Python apps and machine learning jobs. Google Cloud hosts this fra
Single Sign-On (SSO) + AI Agent Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run ray on vertex ai, teams build a managed cluster in Google Cloud. Then they submit distributed Python jobs from a notebook or a local script. Most teams start by assigning a shared service account to the cluster nodes. If that role is too broad, any user job can read private buckets. It can also query production databases without limits.
How ray on vertex ai manages clusters and roles
Ray is an open framework for scaling Python apps and machine learning jobs. Google Cloud hosts this framework so teams do not manage raw virtual machines. You pick the head node size and the worker node counts. You can also attach graphics cards for heavy model training tasks.
When the cluster starts, it uses a Google Cloud service account. This account gives the worker nodes permission to read storage buckets and write logs. Data scientists connect to the head node from a workbench notebook. They can also submit jobs through the client library from a laptop. Once connected, the head node splits the Python job into smaller tasks. It sends those tasks across the worker nodes to run at the same time.
Network rules control how the cluster talks to other internal systems. Teams often pair the cluster with a private cloud network. This step lets worker nodes reach internal databases and data warehouses. Every task running on those workers inherits the same network path and service role.
What native cluster roles solve and what they miss
Native cloud roles control who can create, view, or delete a cluster. They also decide which cloud storage buckets the cluster service account can read. This setup stops outside users from reaching your compute nodes. It also keeps cluster traffic inside your private network.
Still, cloud roles only check who logs in at the start. They do not inspect what individual queries or scripts do in flight. Once a developer connects to the head node, their code runs with cluster permissions. If five people share one cluster, they all share the same database access.
Single Sign-On (SSO) + AI Agent Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Further, worker scripts often need keys to read external databases. Teams store these keys in cloud secret managers and load them into worker memory. A stray script or a bad prompt can print those keys into job logs. Also, training jobs often pull raw tables that hold emails or card numbers. Cloud roles cannot rewrite those matched fields in query results before the worker reads them. You know the cluster queried the database, but you do not know which user ran the query.
Managing database queries and secrets from worker nodes
To reduce risk, teams separate cluster admin rights from data access rights. You should give the cluster service account only the bare minimum cloud permissions. Do not attach broad editor roles to the compute nodes. Create separate clusters for testing and production workloads so test code stays isolated.
Even with separate clusters, worker nodes still run arbitrary Python code against your data. You need a way to check every database query and command in real time. You also need to tie each action back to the individual developer, not the shared cluster.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do data scientists submit jobs to a Ray cluster on Google Cloud?
Developers connect from a managed notebook or use the Python client SDK. The SDK sends the script to the head node, which schedules tasks on workers.
Why is a shared cluster service account a security risk?
Every job on the cluster inherits the permissions of that single service account. One user can run code that reads data meant for a different team.
How can teams protect sensitive data during distributed model training?
Teams restrict the cluster role and inspect database queries in flight. Data masking rewrites matched fields like phone numbers or national IDs in query results.