Vdi Account
You set up a vdi account by linking directory users to a virtual desktop pool. Then you assign host permissions and network rules to that user group. Teams often run virtual desktops to keep data off local laptops. They place SQL tools, cloud consoles, and admin apps inside the remote desktop. Still, engineers inside that desktop often share broad database keys and static server credentials. A broad role on the virtual desktop lets one user touch every backend system. How a vdi account works i
Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a vdi account by linking directory users to a virtual desktop pool. Then you assign host permissions and network rules to that user group. Teams often run virtual desktops to keep data off local laptops. They place SQL tools, cloud consoles, and admin apps inside the remote desktop. Still, engineers inside that desktop often share broad database keys and static server credentials. A broad role on the virtual desktop lets one user touch every backend system.
How a vdi account works in your setup
A vdi account starts in your central directory service. Admins create a user profile and add it to a security group. Next, the desktop manager maps that group to a specific pool of virtual machines. You can pick persistent desktops that save user files between logins. You can also pick non-persistent desktops that wipe all changes when the user logs out.
When an engineer logs in, the system checks their name, password, and multi-factor token. After that check passes, the host starts a desktop session for the user. The virtual machine runs inside your private cloud or data center network. Because the machine sits inside the private network, it can reach internal databases and servers. Admins install database clients and Kubernetes tools on the base image for the team. The engineer opens these local apps inside the remote window to do daily work.
What a vdi account solves and what it misses
Virtual desktops solve the problem of lost or stolen laptops. Raw database files do not sit on a home computer. Admins can cut off a user session by turning off the virtual machine. Network firewalls also have an easier job. They only allow traffic from the virtual desktop subnet to reach internal servers.
Still, a vdi account only controls who logs into the remote desktop screen. It does not check what commands or queries the user runs inside that screen. Once the engineer opens a SQL tool on the desktop, they use a backend login. Teams often store shared database passwords inside the virtual machine to save time. If two engineers use the same database role, the database log shows one shared name. You cannot tell which person ran a drop table statement or read customer rows.
Screen capture tools on the desktop only record video pixels. Security teams cannot search video files for specific SQL queries or terminal flags. Also, video logs do not rewrite sensitive fields like emails, phone numbers, or card numbers. A user who queries a table sees the raw card numbers right on their screen.
Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams separate desktop logins from database roles
Relying on a remote desktop to guard production data mixes two different jobs. The desktop gives a user a workspace, while backend servers hold your real data. When every virtual desktop sits on a trusted subnet, network walls become too open. Any app running inside that desktop can reach the production database port.
To fix this, teams stop treating the virtual desktop subnet as a free pass. They move control down to the actual database query and server command level. Instead of putting static database keys on the desktop image, they check identity per action. Each query ties back to the exact person who ran it. Teams can also review risky commands before they run and mask sensitive fields in results.
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 is the difference between a persistent and non-persistent vdi account?
A persistent setup gives the user the same virtual desktop every time they log in. It saves their local files, app settings, and stored keys across reboots. A non-persistent setup gives the user a fresh machine from a shared pool at login. It wipes all local changes as soon as the session ends.
Does a virtual desktop stop users from copying sensitive database rows?
Admins can turn off clipboard sharing and file transfers on the virtual desktop. Still, users can still view raw emails, phone numbers, or card numbers on their screen. Without field masking on the query result, anyone with a phone camera can capture data.
Why do database logs miss the real user behind a virtual desktop?
The virtual desktop logs the user into the operating system, not the database. Inside the desktop, engineers often connect to databases using a shared team role or key. The database only sees that shared role name, so it cannot log the individual user.