Rubrik Exocompute Azure
You set up rubrik exocompute azure by linking your cloud account to the backup service. The service then spins up short-lived worker nodes inside your own virtual network. Cloud teams often grant broad subscription roles so these worker clusters can start and stop. Broad roles make setup fast, but they give accounts too much power across your cloud. How rubrik exocompute azure works in your cloud The platform uses a temporary cluster inside your account to process backup data. Instead of runn
Azure RBAC: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up rubrik exocompute azure by linking your cloud account to the backup service. The service then spins up short-lived worker nodes inside your own virtual network. Cloud teams often grant broad subscription roles so these worker clusters can start and stop. Broad roles make setup fast, but they give accounts too much power across your cloud.
How rubrik exocompute azure works in your cloud
The platform uses a temporary cluster inside your account to process backup data. Instead of running backup servers all day, the service starts nodes only when needed. It builds a managed container cluster inside a subnet that you pick.
First, you register your cloud account and grant a service principal role to the tool. Next, you pick a region and assign a dedicated subnet for the worker nodes. This subnet needs enough free IP addresses for the temporary nodes to scale up.
When a backup job starts, the control plane sends a request to your cloud account. Your account starts the worker nodes, reads the storage snapshots, and indexes the files. Once the job finishes, the platform shuts down the worker nodes to save money.
Network and role rules for worker nodes
The worker nodes need outbound network paths to talk to the backup control plane. They also need local network paths to reach your cloud storage accounts and disks. Teams often use private endpoints so backup traffic stays off the public internet.
For permissions, the service principal needs rights to create and delete container clusters. It also needs rights to attach disks, read snapshots, and write to storage vaults. Many admins assign a broad owner or contributor role to avoid permission errors during setup.
Over time, these broad roles create security risks across your cloud subscriptions. If a team uses the same role for daily debugging, anyone with that role can change live resources. You should scope the service role down to the exact resource groups needed for backups.
Azure RBAC: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cloud roles solve and what they miss
Native cloud roles do a good job of letting the backup service start worker clusters. They let you define which cloud subscriptions and subnets the backup tool can touch. They also log high-level account events when a cluster starts or stops.
Still, native cloud roles only check who logs in at the start of a session. They do not inspect what individual commands, queries, or requests do in flight. When an engineer logs in to fix a failed node or check a database, the cloud role grants full session power.
A cloud role cannot block a bad drop statement or rewrite sensitive data in query results. If an engineer queries a restored database, raw emails, phone numbers, and card numbers return in full. To control actions inside live sessions, teams need controls that work at the command level.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does the temporary compute cluster do during a backup?
The cluster starts worker nodes to index snapshots, scan files, and move backup data. It shuts the nodes down as soon as the backup job finishes.
Why do worker nodes fail to start in a subnet?
Worker nodes usually fail when the subnet runs out of free IP addresses. They also fail if network rules block outbound traffic to the control plane.
Can native cloud roles hide sensitive fields during database restores?
No, native cloud roles only control who can log in and start a restore. They do not rewrite emails, phone numbers, or national IDs inside live database queries.